From ghc-devs at haskell.org Sun Dec 1 04:31:56 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Dec 2013 04:31:56 -0000 Subject: [GHC] #8581: Add support for explicitly-bidirectional pattern synonyms Message-ID: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> #8581: Add support for explicitly-bidirectional pattern synonyms ------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: 5144 | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Some patterns cannot, by themselves, be turned over into an expression, so they have to be defined as unidirectional. Maybe the most trivial example would be {{{ pattern P -> _ }}} Sometimes, however, it would be desirable to give an explicit way of turning these pattern synonyms into expressions. The PatternSynonyms wiki page has this example: {{{ import qualified Data.Sequence as Seq pattern Empty -> (Seq.viewl -> Seq.EmptyL) pattern x :< xs -> (Seq.viewl -> x Seq.:< xs) pattern xs :> x -> (Seq.viewr -> xs Seq.:> x) }}} It would make a ton of sense to be able to use this cons/snoc notation as "constructors" for `Seq`s. The proposed syntax for this {{{ pattern x :< xs -> (Seq.viewl -> x Seq.:< xs) where x :< xs = x Seq.<| xs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 1 04:39:35 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Dec 2013 04:39:35 -0000 Subject: [GHC] #8582: Record syntax for pattern synonyms Message-ID: <045.711f298e5aa28ce184df85985d614bd2@haskell.org> #8582: Record syntax for pattern synonyms ------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: 5144 | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Implement syntax for {{{ pattern Cons{car, cdr} = (car, cdr) }}} which can then be used just like a regular record constructor, so the following are all valid patterns: {{{ Cons (Just x) [] Cons{car = Just x} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 1 04:41:08 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Dec 2013 04:41:08 -0000 Subject: [GHC] #8583: Associated pattern synonyms Message-ID: <045.39184734af9bc44765e305261b59a6ed@haskell.org> #8583: Associated pattern synonyms ------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: 5144 | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The PatternSynonyms wiki page has a section on (typeclass-)associated pattern synonyms: {{{ class ListLike l where pattern Nil :: l a pattern Cons :: a -> l a -> a isNil :: l a -> Bool isNil Nil = True isNil (Cons _ _) = False append :: l a -> l a -> l a instance ListLike [] where pattern Nil = [] pattern Cons x xs = x:xs append = (++) headOf :: (ListLike l) => l a -> Maybe a headOf Nil = Nothing headOf (Cons x _) = Just x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 1 04:41:43 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Dec 2013 04:41:43 -0000 Subject: [GHC] #8583: Associated pattern synonyms In-Reply-To: <045.39184734af9bc44765e305261b59a6ed@haskell.org> References: <045.39184734af9bc44765e305261b59a6ed@haskell.org> Message-ID: <060.41161a3fe98749440b0e25698352f129@haskell.org> #8583: Associated pattern synonyms -------------------------------------+------------------------------------ Reporter: cactus | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 5144 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by cactus): * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 1 04:44:37 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Dec 2013 04:44:37 -0000 Subject: [GHC] #8584: Pattern synonym type signatures Message-ID: <045.c6cdcd563c8eae8b80969790ee87e736@haskell.org> #8584: Pattern synonym type signatures ------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: 5144 | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Currently, the only way to specify a type signature for a pattern synonym is by adding type annotations to the right-hand side, like this: {{{ {-# LANGUAGE PatternSynonyms, ScopedTypeVariables #-} pattern Single x = ([x] :: [Int]) }}} Bespoke syntax for adding type signatures for pattern synonyms would probably be useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 1 04:46:24 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Dec 2013 04:46:24 -0000 Subject: [GHC] #5144: Pattern synonyms In-Reply-To: <046.358306463908294bbc35edfc129eeda7@haskell.org> References: <046.358306463908294bbc35edfc129eeda7@haskell.org> Message-ID: <061.8b759a12a779e5a556a052166b19a083@haskell.org> #5144: Pattern synonyms -------------------------------------------+------------------------------- Reporter: simonpj | Owner: cactus Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: 8581, 8582, 8583, 8584 | Blocked By: | Related Tickets: -------------------------------------------+------------------------------- Comment (by cactus): I've added separate tickets to the features from the PatternSynonyms page that are not going to be implemented in the initial version (which is now code-complete and just needs some docs and some comments here and there). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 1 09:31:49 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Dec 2013 09:31:49 -0000 Subject: [GHC] #8275: Loopification breaks profiling In-Reply-To: <048.63a98da772d0fcd943c3debc22ba0a20@haskell.org> References: <048.63a98da772d0fcd943c3debc22ba0a20@haskell.org> Message-ID: <063.c4fb5d83d7711a09c68e74fb92f86a4c@haskell.org> #8275: Loopification breaks profiling ----------------------------------------+---------------------------------- Reporter: jstolarek | Owner: jstolarek Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: Profiling | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: 8456 | Related Tickets: ----------------------------------------+---------------------------------- Changes (by jstolarek): * owner: => jstolarek Comment: OK, I got my laptop back :-) Patch validates, but before I push it I want to make a few more tests to see that it does the right thing. > And here's an ugly PoC patch that moves the self-loop label below the stack check: Could you explain how and why this works? I mostly interested in knowing how does it guarantee to place self-loop label after stack check but before heap check. I don't have more time to investigate this at the moment but if the patch is ready and working it would be good to have it pushed. Once I push your patch for loopification I'll close this ticket and start a new one for moving self-loop label after the stack check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 1 09:59:08 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Dec 2013 09:59:08 -0000 Subject: [GHC] #8220: Macros / functions for source location In-Reply-To: <048.0fa927bf37d396108b25d732b1a1b4c2@haskell.org> References: <048.0fa927bf37d396108b25d732b1a1b4c2@haskell.org> Message-ID: <063.0883a6872547eaa1aa0d3254e85d031f@haskell.org> #8220: Macros / functions for source location -------------------------------------+------------------------------------ Reporter: wojteknar | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by literon): The extension in the branch https://github.com/sol/rewrite-with-location/ can help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 1 10:07:14 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Dec 2013 10:07:14 -0000 Subject: [GHC] #8275: Loopification breaks profiling In-Reply-To: <048.63a98da772d0fcd943c3debc22ba0a20@haskell.org> References: <048.63a98da772d0fcd943c3debc22ba0a20@haskell.org> Message-ID: <063.20210fcc21eb42cbd9368316e4f80329@haskell.org> #8275: Loopification breaks profiling ----------------------------------------+---------------------------------- Reporter: jstolarek | Owner: jstolarek Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: Profiling | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: 8456 | Related Tickets: ----------------------------------------+---------------------------------- Comment (by Jan Stolarek ): In [changeset:"adb9964e2f97338501411282c0bb6a9f47a56b1b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="adb9964e2f97338501411282c0bb6a9f47a56b1b" Fix loopification with profiling and enable it by default (#8275) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 1 10:08:21 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Dec 2013 10:08:21 -0000 Subject: [GHC] #8275: Loopification breaks profiling In-Reply-To: <048.63a98da772d0fcd943c3debc22ba0a20@haskell.org> References: <048.63a98da772d0fcd943c3debc22ba0a20@haskell.org> Message-ID: <063.d895ff42839c4df380afbe88ceec8d5f@haskell.org> #8275: Loopification breaks profiling ----------------------------------------+---------------------------------- Reporter: jstolarek | Owner: jstolarek Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Profiling | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: 8456 | Related Tickets: ----------------------------------------+---------------------------------- Changes (by jstolarek): * status: patch => closed * resolution: => fixed Comment: OK, I see how the loopification patch works. Previously we had: {{{ c4AC: call "ccall" arg hints: [PtrHint, PtrHint] result hints: [] enterFunCCS(BaseReg, I64[R1 - 1 + 8]); }}} Now we have: {{{ c4AC: call "ccall" arg hints: [PtrHint, PtrHint] result hints: [] enterFunCCS(BaseReg, I64[_s2UW::P64 - 1 + 8]); }}} The `_s2UW::P64` is declared anyway so no extra work required :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 1 10:15:51 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Dec 2013 10:15:51 -0000 Subject: [GHC] #8585: Loopification should omit stack check Message-ID: <048.357f98b67b6c2b39906af5ad1988d2df@haskell.org> #8585: Loopification should omit stack check ------------------------------+-------------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- When we optimize a self-recursive tail call using loopification we don't need to perform a stack check in every loop. This is because a tail recursive function uses constant amount of stack. We should therefore place the loop header after the stack check, but before the heap check (because heap may grow in every call). parcs proposed a patch [https://ghc.haskell.org/trac/ghc/ticket/8275#comment:34 here]. We just need to make sure why it works and add some documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 1 10:18:08 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Dec 2013 10:18:08 -0000 Subject: [GHC] #8585: Loopification should omit stack check In-Reply-To: <048.357f98b67b6c2b39906af5ad1988d2df@haskell.org> References: <048.357f98b67b6c2b39906af5ad1988d2df@haskell.org> Message-ID: <063.8c9da5a374feba959425af7f79149d17@haskell.org> #8585: Loopification should omit stack check --------------------------------------------+------------------------------ Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by jstolarek): * cc: patrick@?, jan.stolarek@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 1 10:28:37 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Dec 2013 10:28:37 -0000 Subject: [GHC] #8275: Loopification breaks profiling In-Reply-To: <048.63a98da772d0fcd943c3debc22ba0a20@haskell.org> References: <048.63a98da772d0fcd943c3debc22ba0a20@haskell.org> Message-ID: <063.d95ff350cc4a1e895fbce8060b1535e1@haskell.org> #8275: Loopification breaks profiling ----------------------------------------+---------------------------------- Reporter: jstolarek | Owner: jstolarek Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Profiling | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: 8456 | Related Tickets: ----------------------------------------+---------------------------------- Comment (by hvr): btw, shall we mention the new `-floopification` flag in the 7.8.1 release notes? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 1 10:29:07 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Dec 2013 10:29:07 -0000 Subject: [GHC] #8275: Loopification breaks profiling In-Reply-To: <048.63a98da772d0fcd943c3debc22ba0a20@haskell.org> References: <048.63a98da772d0fcd943c3debc22ba0a20@haskell.org> Message-ID: <063.85c70b2e2b0eeccaae2176ecc9b44916@haskell.org> #8275: Loopification breaks profiling ----------------------------------------+---------------------------------- Reporter: jstolarek | Owner: jstolarek Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Profiling | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: 8456 | Related Tickets: ----------------------------------------+---------------------------------- Comment (by Jan Stolarek ): In [changeset:"6d24076be9aff562cd449aa1d39b8eb14638bcd6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6d24076be9aff562cd449aa1d39b8eb14638bcd6" Document solution to #8275 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 1 13:17:25 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Dec 2013 13:17:25 -0000 Subject: [GHC] #8586: internal error: evacuate(static): strange closure type 5189 Message-ID: <044.1c644f7f58d3cc3b77a418e4f5a65979@haskell.org> #8586: internal error: evacuate(static): strange closure type 5189 ----------------------------+------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: crash | Operating System: Windows Architecture: x86 | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+------------------------------- I cannot reproduce this reliably, but it happened once. Here?s what I did: * Install Yesod * Scaffold a blank Yesod project with no DB * Run GHCi * :l Foundation.hs * :info AForm Output: {{{ newtype AForm m a = AForm {unAForm :: (HandlerSite m, [Text]) -> Maybe (Env, FileEnv) -> Ints -> m (FormResult a, [FieldView (HandlerSite m)] -> [FieldView (HandlerSite m)], Ints, Enctype)} -- Defined in `Yesod.Form.Types' instance Monad m => Functor (AForm m) -- Defined in `Yesod.Form.Types' instance (Monad m, Monoid a) => Monoid (AForm m a) -- Defined in `Yesod.Form.Types' instance MonadTransghc.exe: internal error: evacuate(static): strange closure type 5189 (GHC version 7.6.3 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} (P.S. I chose 'x86' for the Architecture because it?s running as 32-bit, but I?m actually using 64-bit Windows.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 1 15:33:45 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Dec 2013 15:33:45 -0000 Subject: [GHC] #8580: Integer size mismatch errors In-Reply-To: <047.d4333db31befff4b75ede8d807b689c8@haskell.org> References: <047.d4333db31befff4b75ede8d807b689c8@haskell.org> Message-ID: <062.434c549a84ae8e336995110cdea21fd4@haskell.org> #8580: Integer size mismatch errors -------------------------------------+------------------------------------- Reporter: heatsink | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86 Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 1 16:37:18 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Dec 2013 16:37:18 -0000 Subject: [GHC] #8493: Can't compile happy + ghc with clang's CPP In-Reply-To: <043.76042121dcfd6c3f0cfaaefb2e590cc6@haskell.org> References: <043.76042121dcfd6c3f0cfaaefb2e590cc6@haskell.org> Message-ID: <058.0cf5167ce7fed422c5316b453f2bd7f2@haskell.org> #8493: Can't compile happy + ghc with clang's CPP ----------------------------------------+---------------------------------- Reporter: maxs | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: libraries (other) | Version: 7.7 Resolution: | Keywords: happy clang Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by George): Not sure if this helps, but with Xcode 5, Mavericks, the latest Haskell platform after running Mark Lentczner script (emailed Oct. 31 to haskell- platform at projects.haskell.org,haskell-cafe at haskell.org, and ghc- devs at haskell.org) I am able to compile happy 1.19.1: cabal install happy Resolving dependencies... Downloading happy-1.19.1... [1 of 1] Compiling Main ( /var/folders/9b/rh4y2gy92hgdb6ktv4df1jv00000gn/T/happy-1.19.1-26867/happy-1.19.1/Setup.lhs, /var/folders/9b/rh4y2gy92hgdb6ktv4df1jv00000gn/T/happy-1.19.1-26867/happy-1.19.1/dist/setup/Main.o ) Linking /var/folders/9b/rh4y2gy92hgdb6ktv4df1jv00000gn/T/happy-1.19.1-26867/happy-1.19.1/dist/setup/setup ... Configuring happy-1.19.1... Building happy-1.19.1... Preprocessing executable 'happy' for happy-1.19.1... ... Linking dist/build/happy/happy ... Warning: No documentation was generated as this package does not contain a library. Perhaps you want to use the --executables, --tests or --benchmarks flags. Installing executable(s) in /Users/gcolpitts/Library/Haskell/ghc-7.6.3/lib/happy-1.19.1/bin Warning: The directory /Users/gcolpitts/Library/Haskell/ghc-7.6.3/lib/happy-1.19.1/bin is not in the system search path. Installed happy-1.19.1 Updating documentation index /Users/gcolpitts/Library/Haskell/doc/index.html Warning: could not create a symlink in /Users/gcolpitts/Library/Haskell/bin for happy because the file exists there already but is not managed by cabal. You can create a symlink for this executable manually if you wish. The executable file has been installed at /Users/gcolpitts/Library/Haskell/ghc-7.6.3/lib/happy-1.19.1/bin/happy bash-3.2$ gcc -v Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include- dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1 Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) Target: x86_64-apple-darwin13.0.0 Thread model: posix bash-3.2$ ghc -v Glasgow Haskell Compiler, Version 7.6.3, stage 2 booted by GHC version 7.4.2 Using binary package database: /Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/package.conf.d/package.cache Using binary package database: /Users/gcolpitts/.ghc/x86_64-darwin-7.6.3/package.conf.d/package.cache hiding package vector-0.10.0.1 to avoid conflict with later version vector-0.10.9.1 hiding package unordered-containers-0.2.3.0 to avoid conflict with later version unordered-containers-0.2.3.3 hiding package hashable-1.1.2.5 to avoid conflict with later version hashable-1.2.1.0 hiding package binary-0.5.1.1 to avoid conflict with later version binary-0.6.4.0 hiding package Cabal-1.16.0 to avoid conflict with later version Cabal-1.18.1.2 hiding package containers-0.5.0.0 to avoid conflict with later version containers-0.5.3.1 hiding package bytestring-0.10.0.2 to avoid conflict with later version bytestring-0.10.4.0 hiding package Cabal-1.18.1.1 to avoid conflict with later version Cabal-1.18.1.2 hiding package blaze-builder-0.3.1.1 to avoid conflict with later version blaze-builder-0.3.2.0 wired-in package ghc-prim mapped to ghc- prim-0.3.0.0-d5221a8c8a269b66ab9a07bdc23317dd wired-in package integer-gmp mapped to integer- gmp-0.5.0.0-2f15426f5b53fe4c6490832f9b20d8d7 wired-in package base mapped to base-4.6.0.1-6c351d70a24d3e96f315cba68f3acf57 wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.8.0.0-c2c1b21dbbb37ace4b7dc26c966ec664 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: -static *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: ghc: no input files Usage: For basic information, try the `--help' option. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 1 17:26:16 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Dec 2013 17:26:16 -0000 Subject: [GHC] #8275: Loopification breaks profiling In-Reply-To: <048.63a98da772d0fcd943c3debc22ba0a20@haskell.org> References: <048.63a98da772d0fcd943c3debc22ba0a20@haskell.org> Message-ID: <063.341d79753a99c40284b8c5913bee4a75@haskell.org> #8275: Loopification breaks profiling ----------------------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Profiling | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: 8456 | Related Tickets: ----------------------------------------+---------------------------------- Changes (by simonmar): * owner: jstolarek => * status: closed => new * resolution: fixed => Comment: The fix looks right to me, thanks. (we should never be referring to global regs explicity except during copy-in or copy-out, so it was just a bug before.) > I don't know whether it's necessary to re-run the LDV code after looping. Not doing so certainly does not cause a segfault, anyway. Yes, it is necessary to do this. Remember that looping should behave in exactly the same way as making a recursive call to the function. Could someone look into this please? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 1 17:36:22 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Dec 2013 17:36:22 -0000 Subject: [GHC] #8587: Add operator <%>, or similar, as <%> = flip fmap Message-ID: <045.4291ceac4a4962ce084701c5834f5623@haskell.org> #8587: Add operator <%>, or similar, as <%> = flip fmap -------------------------------------------+------------------------------- Reporter: bunimo | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Prelude | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Often, piping results through one function after another provides a good conceptual flow to the code. But when the functions are a mixture of monadic and pure, it can seem more convoluted than it actually is. For example, compare: {{{ do a <- monadicResult let b = pureFunction2 . pureFunction 1 <$> a c <- monadicFunction1 b >>= monadicFunction2 }}} to {{{ c <- monadicFunction2 =<< monadicFunction1 =<< pureFunction2 <$> pureFunction1 <$> monadicResult }}} But this reading from bottom-to-up seems backwards, especially considering monadic code is more traditionally top-to-bottom, left-to-right. I'd like to propose adding a new operator {{{ infixl 1 <%> (<%>) :: Functor f => f a -> (a -> b) -> f b (<%>) = flip fmap }}} so that the following can be written. It is obvious what the intent of the code is. There are no unnecessary temporary variables. It conforms to typical monadic code direction. It is visually pleasing. {{{ c <- monadicResult <%> pureFunction1 <%> pureFunction2 >>= monadicFunction1 >>= monadicFunction2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 1 18:09:10 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Dec 2013 18:09:10 -0000 Subject: [GHC] #8587: Add operator <%>, or similar, as <%> = flip fmap In-Reply-To: <045.4291ceac4a4962ce084701c5834f5623@haskell.org> References: <045.4291ceac4a4962ce084701c5834f5623@haskell.org> Message-ID: <060.88a2b4b43850790022ffaa1bfc1eb74d@haskell.org> #8587: Add operator <%>, or similar, as <%> = flip fmap -------------------------------+------------------------------------------- Reporter: bunimo | Owner: Type: feature | Status: closed request | Milestone: _|_ Priority: normal | Version: 7.6.3 Component: Prelude | Keywords: Resolution: invalid | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by monoidal): * status: new => closed * resolution: => invalid Comment: Proposals to add new functions or instances should be discussed on the [http://www.haskell.org/mailman/listinfo/libraries libraries mailing list] first. Once you get approval, you can paste a link to the discussion here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 1 19:33:47 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Dec 2013 19:33:47 -0000 Subject: [GHC] #8588: ForeignImport coercion evaluated before typechecking Message-ID: <046.d4d2c12c86b782a8f2b670cdefa006ee@haskell.org> #8588: ForeignImport coercion evaluated before typechecking ----------------------------------+---------------------------- Reporter: zcourts | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------- I'm fairly new to Haskell by all accounts this could have been caused by me doing something silly. Following the real world haskell book's directions on the FFI resulted in: "Multiple markers at this line: - buildwrapper.exe: panic! (the 'impossible' happened) (GHC version 7.6.3 for i386-unknown-mingw32): ForeignImport coercion evaluated before typechecking Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug - 16 changed lines" I went to the Haskell Wiki to try an example from there to see if the RWH e.g. was just out dated. All examples I've come across causes this error inc. those at http://www.haskell.org/haskellwiki/FFI_complete_examples#Calling_standard_library_functions and reading https://www.haskell.org/ghc/docs/7.6.3/users_guide.pdf FFI section didn't help. The current failing code is {{{ {-# LANGUAGE ForeignFunctionInterface #-} module Events.CEvent where import Prelude hiding (sin) import Foreign.C -- get the C types import Foreign.Ptr (Ptr,nullPtr) -- pure function foreign import ccall "sin" c_sin :: CDouble -> CDouble sin :: Double -> Double sin d = realToFrac (c_sin (realToFrac d)) -- impure function foreign import ccall "time" c_time :: Ptr a -> IO CTime getTime :: IO CTime getTime = c_time nullPtr }}} I've also tried this which causes the same error {{{ {-# LANGUAGE ForeignFunctionInterface #-} module Events.Event2 where import Foreign import Foreign.C.Types foreign import ccall "math.h sin" c_sin :: CDouble -> CDouble }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 1 19:47:07 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Dec 2013 19:47:07 -0000 Subject: [GHC] #8588: ForeignImport coercion evaluated before typechecking In-Reply-To: <046.d4d2c12c86b782a8f2b670cdefa006ee@haskell.org> References: <046.d4d2c12c86b782a8f2b670cdefa006ee@haskell.org> Message-ID: <061.818180d5fdd6f97e48a6a60c7232562b@haskell.org> #8588: ForeignImport coercion evaluated before typechecking -----------------------------+---------------------------------- Reporter: zcourts | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: invalid | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Changes (by zcourts): * status: new => closed * resolution: => invalid Comment: As usual stuff doesn't become obvious until after you've made a fool of yourself on the NET. The one thing I hadn't tried was building from the terminal. Doing so everything builds and links fine and I'm able to execute the C function using ghci. I'm using http://eclipsefp.github.io/ so it must be a bug in the BuildWrapper it's using -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 1 20:04:08 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Dec 2013 20:04:08 -0000 Subject: [GHC] #8498: gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure) In-Reply-To: <045.6e47836af0f0e307f79949999a773a19@haskell.org> References: <045.6e47836af0f0e307f79949999a773a19@haskell.org> Message-ID: <060.a4333787fd2a1fedcd9f9961ff822f66@haskell.org> #8498: gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure) ---------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by adamse): To compile GHC on commit 6d24076be9aff562cd449aa1d39b8eb14638bcd6 I had to specify a working compiler (I used a clang wrapper) in the `settings` file for my bootstrapping ghc. Located at `/Library/Frameworks/GHC.framework/Versions/Current/usr/lib/ghc-7.4.2/settings` for the latest Haskell platform I believe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 1 22:48:07 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Dec 2013 22:48:07 -0000 Subject: [GHC] #8275: Loopification breaks profiling In-Reply-To: <048.63a98da772d0fcd943c3debc22ba0a20@haskell.org> References: <048.63a98da772d0fcd943c3debc22ba0a20@haskell.org> Message-ID: <063.a71f95019a77803de3f249226b44c74e@haskell.org> #8275: Loopification breaks profiling ----------------------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Profiling | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: 8456 | Related Tickets: ----------------------------------------+---------------------------------- Comment (by Patrick Palka ): In [changeset:"ac31b79924e9330c577ea63af9b0f10f4fc6c8f6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ac31b79924e9330c577ea63af9b0f10f4fc6c8f6" Move the LDV code below the self-loop label (#8275) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 1 22:49:19 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Dec 2013 22:49:19 -0000 Subject: [GHC] #8275: Loopification breaks profiling In-Reply-To: <048.63a98da772d0fcd943c3debc22ba0a20@haskell.org> References: <048.63a98da772d0fcd943c3debc22ba0a20@haskell.org> Message-ID: <063.70ef5ca2a05d1caeb94c5eff9c5257c9@haskell.org> #8275: Loopification breaks profiling ----------------------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Profiling | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: 8456 | Related Tickets: ----------------------------------------+---------------------------------- Comment (by parcs): Replying to [comment:40 simonmar]: > The fix looks right to me, thanks. (we should never be referring to global regs explicity except during copy-in or copy-out, so it was just a bug before.) > > > I don't know whether it's necessary to re-run the LDV code after looping. Not doing so certainly does not cause a segfault, anyway. > > Yes, it is necessary to do this. Remember that looping should behave in exactly the same way as making a recursive call to the function. Could someone look into this please? Okay, I optimistically pushed a pair of commits to make the LDV coderun after looping. It involved eliminating another explicit use of `nodeReg` and then moving the LDV code below the self-loop label. Is this fine? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 1 23:35:40 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Dec 2013 23:35:40 -0000 Subject: [GHC] #8493: Can't compile happy + ghc with clang's CPP In-Reply-To: <043.76042121dcfd6c3f0cfaaefb2e590cc6@haskell.org> References: <043.76042121dcfd6c3f0cfaaefb2e590cc6@haskell.org> Message-ID: <058.a6e396aa55c9ec2def09a65e0504865f@haskell.org> #8493: Can't compile happy + ghc with clang's CPP ----------------------------------------+---------------------------------- Reporter: maxs | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: libraries (other) | Version: 7.7 Resolution: fixed | Keywords: happy clang Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by carter): * status: new => closed * resolution: => fixed Comment: I think this issue *should be resolved now* make sure you're using the newest version of HAPPY and ALEX on hackage please open a new ticket with more information if you're still having problems -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 2 00:37:25 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Dec 2013 00:37:25 -0000 Subject: [GHC] #5019: OS X: ld: warning: could not create compact unwind for _ffi_call_unix64 In-Reply-To: <045.b69a18db2d8262d9c9f3c4458d59e3ad@haskell.org> References: <045.b69a18db2d8262d9c9f3c4458d59e3ad@haskell.org> Message-ID: <060.7de2ef901a0078dfad3fe44e7ba8f347@haskell.org> #5019: OS X: ld: warning: could not create compact unwind for _ffi_call_unix64 -------------------------------------------------+------------------------- Reporter: altaic | Owner: Type: bug | Status: Priority: high | infoneeded Component: Compiler | Milestone: 7.8.1 Resolution: | Version: 7.1 Operating System: MacOS X | Keywords: Type of failure: Incorrect warning at | Architecture: compile-time | x86_64 (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by George): * status: new => infoneeded Comment: Is this still happening or limited to the 32 bit version of Haskell? I haven't seen it in at least a year now. If it is still happening it would be nice if there was a description of an easy way to reproduce. I am now using Xcode 5 and OS X Mavericks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 2 00:50:21 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Dec 2013 00:50:21 -0000 Subject: [GHC] #7011: 32bit GHC 7.4.2 cannot compile integer-gmp on OS X 10.8 In-Reply-To: <043.9c0c6ae0a9ecc6b011a4e64a0d3b06e3@haskell.org> References: <043.9c0c6ae0a9ecc6b011a4e64a0d3b06e3@haskell.org> Message-ID: <058.3888b1e04f921501095e87b8bfd4d90d@haskell.org> #7011: 32bit GHC 7.4.2 cannot compile integer-gmp on OS X 10.8 --------------------------------------+--------------------------------- Reporter: chak | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.1 Component: libraries (other) | Version: 7.5 Resolution: | Keywords: Mountain Lion Operating System: MacOS X | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+--------------------------------- Changes (by George): * status: new => infoneeded Comment: Is this still a problem with Xcode 5 on Mountain Lion or OS X Mavericks? If it is still a problem is it a problem with both the 32 and 64 bit versions of Haskell? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 2 08:18:43 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Dec 2013 08:18:43 -0000 Subject: [GHC] #8275: Loopification breaks profiling In-Reply-To: <048.63a98da772d0fcd943c3debc22ba0a20@haskell.org> References: <048.63a98da772d0fcd943c3debc22ba0a20@haskell.org> Message-ID: <063.6f407e2b68d19b4ab8bfdf3dfc4f3b07@haskell.org> #8275: Loopification breaks profiling ----------------------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Profiling | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: 8456 | Related Tickets: ----------------------------------------+---------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Ok, looks good, thanks. I'll re-open if I find any problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 2 09:08:45 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Dec 2013 09:08:45 -0000 Subject: [GHC] #8576: Improve deriving error messages In-Reply-To: <046.f04aff3ace8ba1f81c9f829b37cc4f2d@haskell.org> References: <046.f04aff3ace8ba1f81c9f829b37cc4f2d@haskell.org> Message-ID: <061.6d45152f65d22029615250d4ca9a3687@haskell.org> #8576: Improve deriving error messages --------------------------------------------+------------------------------ Reporter: nomeata | Owner: nomeata Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type checker) | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by nomeata): Theoretically possible, but would require a decent amount of code reshuffling: The `CtOrigin` is currently created in `derivTyData` (and others), and passed down to `mkEqnHelp` to `mkDataTypeEqn` to `mk_data_eqn`, where the `inferred_constraints`, which are obtained from `inferConstraints` as a list, put together with the `CtOrigin` and put into one `EarlyDerivSpec`, which does not support different `CtOrigin`s for different constraints. I do like fancy error messages, but the code (passing around plain `[Type]` for the constraint) has some elegance. Is this feature worth uprooting that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 2 10:03:50 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Dec 2013 10:03:50 -0000 Subject: [GHC] #8567: Poor error message when GeneralizedNewtypeDeriving fails In-Reply-To: <047.019b4a48a0a3d68a214e0cd69bcf8b30@haskell.org> References: <047.019b4a48a0a3d68a214e0cd69bcf8b30@haskell.org> Message-ID: <062.42fd7044c537bbb4a2c70b4b7c0e0c84@haskell.org> #8567: Poor error message when GeneralizedNewtypeDeriving fails -------------------------------------+------------------------------------ Reporter: goldfire | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Was straight forward to implement, validate is running... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 2 11:11:57 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Dec 2013 11:11:57 -0000 Subject: [GHC] #8567: Poor error message when GeneralizedNewtypeDeriving fails In-Reply-To: <047.019b4a48a0a3d68a214e0cd69bcf8b30@haskell.org> References: <047.019b4a48a0a3d68a214e0cd69bcf8b30@haskell.org> Message-ID: <062.19f0a98bdaf8f3f47c6ca2c7f93e7de8@haskell.org> #8567: Poor error message when GeneralizedNewtypeDeriving fails -------------------------------------+------------------------------------ Reporter: goldfire | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"1791ea0abf446bc7221f713d715f4bf87dc6af47/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1791ea0abf446bc7221f713d715f4bf87dc6af47" Print nicer error message for Coercible errors It now reads Could not coerce from ?S a? to ?S (NT a)? and does not mention Coercible any more (as discussed in #8567). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 2 11:40:02 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Dec 2013 11:40:02 -0000 Subject: [GHC] #8567: Poor error message when GeneralizedNewtypeDeriving fails In-Reply-To: <047.019b4a48a0a3d68a214e0cd69bcf8b30@haskell.org> References: <047.019b4a48a0a3d68a214e0cd69bcf8b30@haskell.org> Message-ID: <062.bf0f1e7ddf57644980af8f73e48d1cc4@haskell.org> #8567: Poor error message when GeneralizedNewtypeDeriving fails -------------------------------------+------------------------------------ Reporter: goldfire | Owner: nomeata Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * status: new => closed * resolution: => fixed Comment: This is implemented and in master, see the test suite update at 522563a27b630b63d18e0ec6fa09c7b5eb6ab6c1 for how the messages look like now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 2 12:27:59 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Dec 2013 12:27:59 -0000 Subject: [GHC] #8589: Bad choice of loop breaker with INLINABLE/INLINE Message-ID: <052.029d6667ad632c5148f8f98b3c4c0bd3@haskell.org> #8589: Bad choice of loop breaker with INLINABLE/INLINE ------------------------------+-------------------------------------------- Reporter: | Owner: NickSmallbone | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime performance bug Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- Take the following program, which defines a pair of lists recursively: {{{ module Test(xs, ys) where pair :: ([Bool], [Bool]) pair = (False:xs, True:ys) where (xs, ys) = pair (xs, ys) = pair }}} GHC is clever enough to disentangle {{{xs}}} from {{{ys}}} and with {{{-ddump-simpl -O}}} I get: {{{ Rec { xs [Occ=LoopBreaker] :: [Bool] [GblId, Caf=NoCafRefs, Str=DmdType] xs = : False xs end Rec } Rec { ys [Occ=LoopBreaker] :: [Bool] [GblId, Caf=NoCafRefs, Str=DmdType] ys = : True ys end Rec } }}} However, if I mark {{{pair}}} as {{{INLINABLE}}} or {{{INLINE}}} (it doesn't matter which), I get much worse code where {{{xs}}} and {{{ys}}} go through {{{pair}}}: {{{ Rec { pair [InlPrag=INLINABLE[ALWAYS], Occ=LoopBreaker] :: ([Bool], [Bool]) [GblId, Str=DmdType m, Unf=Unf{Src=InlineStable, TopLvl=True, Arity=0, Value=True, ConLike=True, WorkFree=False, Expandable=True, Guidance=IF_ARGS [] 50 30 Tmpl= (: False (case pair of _ { (xs1_Xf6 [Occ=Once], _) -> xs1_Xf6 }), : True (case pair of _ { (_, ys1_Xf6 [Occ=Once]) -> ys1_Xf6 }))}] pair = (a1_rgo, a_rgn) ys_ys :: [Bool] [GblId, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Arity=0, Value=False, ConLike=False, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 0}] ys_ys = case pair of _ { (xs1_XeW, ys1_Xf7) -> ys1_Xf7 } a_rgn :: [Bool] [GblId, Str=DmdType] a_rgn = : True ys_ys xs_xs :: [Bool] [GblId, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Arity=0, Value=False, ConLike=False, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 0}] xs_xs = case pair of _ { (xs1_XeW, ys1_XeS) -> xs1_XeW } a1_rgo :: [Bool] [GblId, Str=DmdType] a1_rgo = : False xs_xs end Rec } ys :: [Bool] [GblId, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Arity=0, Value=False, ConLike=False, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(unsat_ok=True,boring_ok=True)}] ys = ys_ys xs :: [Bool] [GblId, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Arity=0, Value=False, ConLike=False, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(unsat_ok=True,boring_ok=True)}] xs = xs_xs }}} It seems that GHC chooses {{{pair}}} as the loop breaker, which stops the simplifier in its tracks. It might seem a bit silly to mark {{{pair}}} as {{{INLINE}}}, since it's not mutually recursive. The function I really had was polymorphic with a typeclass constraint, and I wrote {{{INLINABLE}}} to get it specialised at its call site. (Also, {{{pair}}} is mutually recursive in the Core, so you would expect GHC to avoid using it as a loop breaker if I mark it {{{INLINE}}}.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 2 13:19:31 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Dec 2013 13:19:31 -0000 Subject: [GHC] #8589: Bad choice of loop breaker with INLINABLE/INLINE In-Reply-To: <052.029d6667ad632c5148f8f98b3c4c0bd3@haskell.org> References: <052.029d6667ad632c5148f8f98b3c4c0bd3@haskell.org> Message-ID: <067.8f3c7dab77062bc4ccfc006ddb821852@haskell.org> #8589: Bad choice of loop breaker with INLINABLE/INLINE --------------------------------------------+------------------------------ Reporter: NickSmallbone | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by tibbe): Aside: I've seen other cases where INLINE and INLINABLE makes things worse that are related to other optimizations being inhibited (i.e. not due to code size increase). I find it slightly worrying that INLINE has other effects than making an expression look cheap (i.e. the original, unoptimized core is inlined, at which point it might be too late for optimization to happen). I understand the reason (rules) we made INLINE behave differently, but perhaps we need two pragmas? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 2 13:33:37 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Dec 2013 13:33:37 -0000 Subject: [GHC] #5869: Compiling the Haskell bindings for ROSE causes a ghc panic In-Reply-To: <043.a3b53eaad76d38bf52d88b656812de02@haskell.org> References: <043.a3b53eaad76d38bf52d88b656812de02@haskell.org> Message-ID: <058.c0951d5752a7109f9e9d0dcd0d2ab30e@haskell.org> #5869: Compiling the Haskell bindings for ROSE causes a ghc panic ---------------------------------------+---------------------------------- Reporter: axch | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by Joachim Breitner ): In [changeset:"7baefa874d858ec1dd8f875a46eb4be5a732875e/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="7baefa874d858ec1dd8f875a46eb4be5a732875e" Mark type-rep as broken until #5869 is fixed }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 2 13:38:49 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Dec 2013 13:38:49 -0000 Subject: [GHC] #1012: ghc panic with mutually recursive modules and template haskell In-Reply-To: <044.e3ec0fd0938800cc6a7ce608eb8687c2@haskell.org> References: <044.e3ec0fd0938800cc6a7ce608eb8687c2@haskell.org> Message-ID: <059.c9261066df35e2cb9ebe55bd7f9b244b@haskell.org> #1012: ghc panic with mutually recursive modules and template haskell -------------------------------------+------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: Template Haskell | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: TH_import_loop | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"84b4e9b4e2f1de48d573ec5035a687d318f7b651/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="84b4e9b4e2f1de48d573ec5035a687d318f7b651" TH_import_loops fails for GHCi again This reverts commit c0e50e9214b5ecb21435d7da70986d30d6128402 and is related to ticket #1012. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 2 16:51:13 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Dec 2013 16:51:13 -0000 Subject: [GHC] #8569: ASSERT in testcase type-rep, only in some ways: In-Reply-To: <046.d7161ae2625fe2a79685c11907883efc@haskell.org> References: <046.d7161ae2625fe2a79685c11907883efc@haskell.org> Message-ID: <061.3b472bfa21de7251cdc34e627a6c5df2@haskell.org> #8569: ASSERT in testcase type-rep, only in some ways: -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): In [changeset:"7baefa874d858ec1dd8f875a46eb4be5a732875e/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="7baefa874d858ec1dd8f875a46eb4be5a732875e" Mark type-rep as broken until #8569 is fixed }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 2 21:38:09 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Dec 2013 21:38:09 -0000 Subject: [GHC] #8590: Reduce code size of CAFs Message-ID: <044.abfe0e6f5cd5b3fe2a2632f41576ec73@haskell.org> #8590: Reduce code size of CAFs ------------------------------------+------------------------------------- Reporter: parcs | Owner: parcs Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The size of each CAF could be reduced by moving the code that allocates the blackhole indirection closure out from the CAF's closure body and into `newCAF`. This saves around 50 bytes of object code per CAF. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 2 21:45:24 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Dec 2013 21:45:24 -0000 Subject: [GHC] #8590: Reduce code size of CAFs In-Reply-To: <044.abfe0e6f5cd5b3fe2a2632f41576ec73@haskell.org> References: <044.abfe0e6f5cd5b3fe2a2632f41576ec73@haskell.org> Message-ID: <059.35e369de736066575952aaf532ce0ee2@haskell.org> #8590: Reduce code size of CAFs -------------------------------------+------------------------------------ Reporter: parcs | Owner: parcs Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by parcs): * status: new => patch Comment: Proposed patch attached. To illustrate the change in code generation, consider the module {{{ #!haskell module CAF where a = "test" }}} Previously, the output Cmm looked like {{{ #!c CAF.a_entry() // [R1] { info_tbl: [(cCO, label: CAF.a_info rep:HeapRep static { Thunk })] stack_info: arg_space: 8 updfr_space: Just 8 } {offset cCO: _rnT::P64 = R1; if ((Sp + -16) < SpLim) goto cCP; else goto cCQ; cCQ: Hp = Hp + 16; if (Hp > HpLim) goto cCS; else goto cCR; cCS: HpAlloc = 16; goto cCP; cCP: R1 = _rnT::P64; call (stg_gc_enter_1)(R1) args: 8, res: 0, upd: 8; cCR: I64[Hp - 8] = stg_CAF_BLACKHOLE_info; I64[Hp] = CurrentTSO; (_cCK::I64) = call "ccall" arg hints: [PtrHint, PtrHint, PtrHint] result hints: [] newCAF(BaseReg, _rnT::P64, Hp - 8); if (_cCK::I64 == 0) goto cCM; else goto cCL; cCM: call (I64[_rnT::P64])() args: 8, res: 0, upd: 8; cCL: I64[Sp - 16] = stg_bh_upd_frame_info; P64[Sp - 8] = Hp - 8; R2 = cCN_str; Sp = Sp - 16; call GHC.CString.unpackCString#_info(R2) args: 24, res: 0, upd: 24; } }}} Now, the output Cmm looks like {{{ #!c CAF.a_entry() // [R1] { info_tbl: [(cCN, label: CAF.a_info rep:HeapRep static { Thunk })] stack_info: arg_space: 8 updfr_space: Just 8 } {offset cCN: if ((Sp + -16) < SpLim) goto cCO; else goto cCP; cCO: R1 = R1; call (stg_gc_enter_1)(R1) args: 8, res: 0, upd: 8; cCP: (_cCJ::I64) = call "ccall" arg hints: [PtrHint, PtrHint] result hints: [PtrHint] newCAF(BaseReg, R1); if (_cCJ::I64 == 0) goto cCL; else goto cCK; cCL: call (I64[R1])() args: 8, res: 0, upd: 8; cCK: I64[Sp - 16] = stg_bh_upd_frame_info; I64[Sp - 8] = _cCJ::I64; R2 = cCM_str; Sp = Sp - 16; call GHC.CString.unpackCString#_info(R2) args: 24, res: 0, upd: 24; } }}} Comparing object sizes: Before: {{{ text data bss dec hex filename 146 32 0 178 b2 caf.o }}} After: {{{ text data bss dec hex filename 92 32 0 124 7c caf.o }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 2 21:53:52 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Dec 2013 21:53:52 -0000 Subject: [GHC] #8590: Reduce code size of CAFs In-Reply-To: <044.abfe0e6f5cd5b3fe2a2632f41576ec73@haskell.org> References: <044.abfe0e6f5cd5b3fe2a2632f41576ec73@haskell.org> Message-ID: <059.b4dea1c0252924ab54591dd34d04c0d4@haskell.org> #8590: Reduce code size of CAFs -------------------------------------+------------------------------------ Reporter: parcs | Owner: parcs Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Nice. Have you also measured the effect on the runtime of programs? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 2 22:04:24 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Dec 2013 22:04:24 -0000 Subject: [GHC] #8590: Reduce code size of CAFs In-Reply-To: <044.abfe0e6f5cd5b3fe2a2632f41576ec73@haskell.org> References: <044.abfe0e6f5cd5b3fe2a2632f41576ec73@haskell.org> Message-ID: <059.8f0562110f352ca3905bed6e3120c1cf@haskell.org> #8590: Reduce code size of CAFs -------------------------------------+------------------------------------ Reporter: parcs | Owner: parcs Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by parcs): Replying to [comment:2 nomeata]: > Nice. Have you also measured the effect on the runtime of programs? No, I haven't. Doing so now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 2 22:44:35 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Dec 2013 22:44:35 -0000 Subject: [GHC] #8590: Reduce code size of CAFs In-Reply-To: <044.abfe0e6f5cd5b3fe2a2632f41576ec73@haskell.org> References: <044.abfe0e6f5cd5b3fe2a2632f41576ec73@haskell.org> Message-ID: <059.61d198d7268b253453f7c0a6239e001c@haskell.org> #8590: Reduce code size of CAFs -------------------------------------+------------------------------------ Reporter: parcs | Owner: parcs Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by parcs): Runtime results are mixed (likely noise I think) Allocation doesn't change except with cacheprof which sees an increase of 0.6%.. Binary size changes between -3.5% to -1.3% Compile-time allocation changes between -10.3% to 0% -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 3 01:27:35 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Dec 2013 01:27:35 -0000 Subject: [GHC] #8591: Concurrent executions of ghc-pkg can cause inconstant package.cache files Message-ID: <043.a3488e266c60ca4bd6e26849ff539dcb@haskell.org> #8591: Concurrent executions of ghc-pkg can cause inconstant package.cache files ------------------------------------+---------------------------- Reporter: janm | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.6.3 Keywords: ghc-pkg race | Operating System: FreeBSD Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+---------------------------- I am doing 24 way parallel builds of system images, including all packages on a system. This includes ghc and multiple ghc packages. I am seeing intermittent dependency failure from the ghc packaging system. From examining Main.hs in ghc-pkg, I see the function withFileAtomic write to a temporary file in package.conf.d and then atomically rename on top of a target file, package.cache in the case. With parallel execution the last rename would win, leading to lost entries in package.cache. In my case, the following things happened: ("Building" indicates a start, "Built" indicates completion, "Installing" is setup in a separate chroot'd environment and is isolated) The FreeBSD ports system is used to drive the Haskell build system. The process works single threaded and fails intermittently when done in parallel. Building: devel/hs-data-default-instances-base Building: devel/hs-data-default-instances-containers Building: devel/hs-data-default-instances-old-locale Built: devel/hs-dlist Building: devel/hs-data-default-instances-dlist Built: devel/hs-temporary Built: jail-image-full Installing: system-image__jail-image-full Built: devel/hs-base64-bytestring Built: archivers/hs-zlib Building: security/hs-digest Built: devel/hs-syb Building: textproc/hs-hs-bibutils Building: textproc/hs-pandoc-types Built: devel/hs-utf8-string Built: devel/hs-data-default-instances-old-locale Built: devel/hs-data-default-instances-containers Built: devel/hs-data-default-instances-base Built: devel/hs-data-default-instances-dlist Building: devel/hs-data-default Built: devel/hs-random Installed: system-image__lang/ghc Installing: system-image__archivers/hs-zlib Installing: system-image__devel/hs-utf8-string Installing: system-image__devel/hs-syb Installing: system-image__devel/hs-base64-bytestring Installing: system-image__devel/hs-data-default-class Installing: system-image__devel/hs-dlist Installing: system-image__devel/hs-random Installing: system-image__devel/hs-temporary Installing: system-image__devel/hs-extensible-exceptions Built: devel/hs-data-default FAILED The error from the Haskell data-default build was: setup: At least the following dependencies are missing: data-default-instances-base -any Looking in the in the package.conf.d directory shows that the data- default-instances-base-0.0.1-7bdf8678f0d8637e096e397e7910f82a.conf file was present, but running "ghc-pkg list" did not show data-default- instances-base Running /usr/local/lib/cabal/ghc-7.6.3/data-default-instances- base-0.0.1/register.sh (which was also present) caused ghc-pkg to now show data-default-instances-base. To me this looks like a race condition between multiple instances of ghc- pkg causing the cache to become inconsistent. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 3 08:35:51 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Dec 2013 08:35:51 -0000 Subject: [GHC] #8590: Reduce code size of CAFs In-Reply-To: <044.abfe0e6f5cd5b3fe2a2632f41576ec73@haskell.org> References: <044.abfe0e6f5cd5b3fe2a2632f41576ec73@haskell.org> Message-ID: <059.2294987fa0f1ae2af4a3625e3d449b27@haskell.org> #8590: Reduce code size of CAFs -------------------------------------+------------------------------------ Reporter: parcs | Owner: parcs Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): Yes, this is a good plan. I think I considered it before but I was worried about the cost of `allocate` vs. inline allocation in the CAF code, but I think a 2% reduction in code size is worth far more, and CAF entry is a one-time cost. So go ahead! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 3 10:13:03 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Dec 2013 10:13:03 -0000 Subject: [GHC] #8419: add rawSystem variant that takes an environment In-Reply-To: <044.1336ed0d15ff978db053dbcdcdc7efa1@haskell.org> References: <044.1336ed0d15ff978db053dbcdcdc7efa1@haskell.org> Message-ID: <059.061e9a0ae4a38bb065aa2c652158aff6@haskell.org> #8419: add rawSystem variant that takes an environment --------------------------------------+------------------------------------ Reporter: dagit | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/process | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Description changed by hvr: Old description: > rawSystem properly handles the case of ^C while waiting. Instead of > requiring people to recreate this behavior when using runProcess, it > would be good if we add and export a rawSystemWithEnv or directly export > syncProcess. > > See for example: https://github.com/haskell/cabal/issues/1448 New description: `rawSystem` properly handles the case of `Ctl-C` while waiting. Instead of requiring people to recreate this behavior when using `runProcess`, it would be good if we add and export a `rawSystemWithEnv` or directly export `syncProcess`. See for example: https://github.com/haskell/cabal/issues/1448 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 3 10:21:15 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Dec 2013 10:21:15 -0000 Subject: [GHC] #2233: Overhaul System.Process In-Reply-To: <047.24a366415ff9b59c03e5bf49850898a6@haskell.org> References: <047.24a366415ff9b59c03e5bf49850898a6@haskell.org> Message-ID: <062.af9d8b8ab47bbafc4cf089f7f9dbffcf@haskell.org> #2233: Overhaul System.Process --------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: task | Status: closed Priority: normal | Milestone: _|_ Component: libraries/process | Version: 6.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by hvr): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 3 10:21:29 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Dec 2013 10:21:29 -0000 Subject: [GHC] #2301: Proper handling of SIGINT/SIGQUIT In-Reply-To: <045.f06a53427920f75d02000e2372e27573@haskell.org> References: <045.f06a53427920f75d02000e2372e27573@haskell.org> Message-ID: <060.9f14df015bdac3d1517fccd2587b59d3@haskell.org> #2301: Proper handling of SIGINT/SIGQUIT -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: | Version: 6.12.3 libraries/process | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: POSIX | Difficulty: Unknown Type of failure: Incorrect result | Blocked By: at runtime | Related Tickets: Test Case: | #3994,#5766,#7229,#4274,#3318,#1619 Blocking: | -------------------------------------+------------------------------------- Changes (by hvr): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 3 10:26:40 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Dec 2013 10:26:40 -0000 Subject: [GHC] #2233: Overhaul System.Process In-Reply-To: <047.24a366415ff9b59c03e5bf49850898a6@haskell.org> References: <047.24a366415ff9b59c03e5bf49850898a6@haskell.org> Message-ID: <062.cd28e5ab44c5bf114eb659eec107cc67@haskell.org> #2233: Overhaul System.Process --------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: task | Status: closed Priority: normal | Milestone: _|_ Component: libraries/process | Version: 6.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"776a260be009cc27cfeacf298934d544c4e87408/process"]: {{{ #!CommitTicketReference repository="process" revision="776a260be009cc27cfeacf298934d544c4e87408" Make `cleanupProcess` resistant to SIGPIPE Otherwise, `cleanupProcess` may exit prematurely if trying to flush out data to the process' stdin handle even though the endpoint has already vanished, and fail to complete the cleanup process. See also 228297ec53e9ee7a1a6a3c5964ca7e89a6474c9b and #2233. Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 3 10:26:40 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Dec 2013 10:26:40 -0000 Subject: [GHC] #2233: Overhaul System.Process In-Reply-To: <047.24a366415ff9b59c03e5bf49850898a6@haskell.org> References: <047.24a366415ff9b59c03e5bf49850898a6@haskell.org> Message-ID: <062.f9db232af62d44df831100b09e3db723@haskell.org> #2233: Overhaul System.Process --------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: task | Status: closed Priority: normal | Milestone: _|_ Component: libraries/process | Version: 6.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"edda1be660d07b461da75b2dfacc3d5820b4d084/process"]: {{{ #!CommitTicketReference repository="process" revision="edda1be660d07b461da75b2dfacc3d5820b4d084" Add Haddock note to `call{Command,Process}` wrt execptions (#2233) This also tweaks Haddock comments & markup in "System.Process" while at it. Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 3 13:27:34 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Dec 2013 13:27:34 -0000 Subject: [GHC] #8592: FunDep error message regression Message-ID: <046.0e5c71777ac391c49229f8cb6d6cafaa@haskell.org> #8592: FunDep error message regression -------------------------------------------+------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- This code (provided by Cale Gibbard) {{{ #!haskell {-# LANGUAGE FunctionalDependencies, FlexibleContexts #-} class C a b | a -> b where foo :: a -> b instance C Integer Integer where foo = id f :: Integer -> String f = foo }}} produced this error message in GHC 7.6: {{{ fundep.hs:10:5: Couldn't match type `Integer' with `String' When using functional dependencies to combine C Integer Integer, arising from the dependency `a -> b' in the instance declaration at fundep.hs:6:10 C Integer String, arising from a use of `foo' at fundep.hs:10:5-7 In the expression: foo In an equation for `f': f = foo }}} but this one with GHC HEAD {{{ FunDepError.hs:11:5: No instance for (C Integer String) arising from a use of ?foo? In the expression: foo In an equation for ?f?: f = foo }}} which seems to be a regression. It may be that either message is fine (it seems to be in this case), In that case, this bug is about the test suite not having a test case for where we do want to see the `When using functional dependencies to combine` message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 3 13:27:55 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Dec 2013 13:27:55 -0000 Subject: [GHC] #8576: Improve deriving error messages In-Reply-To: <046.f04aff3ace8ba1f81c9f829b37cc4f2d@haskell.org> References: <046.f04aff3ace8ba1f81c9f829b37cc4f2d@haskell.org> Message-ID: <061.3e9f1d4a15bc553b7a6cc0fe0a313521@haskell.org> #8576: Improve deriving error messages --------------------------------------------+------------------------------ Reporter: nomeata | Owner: nomeata Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type checker) | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Joachim Breitner ): In [changeset:"4025d66cc795b728f745aec23fc5c2267d1839f0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4025d66cc795b728f745aec23fc5c2267d1839f0" Elaborate "deriving" error messages If "deriving (C)" fails, it will now, if possible, indicate which particular field of which constructor has caused the failure. (This fixes #8576) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 3 13:28:12 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Dec 2013 13:28:12 -0000 Subject: [GHC] #8576: Improve deriving error messages In-Reply-To: <046.f04aff3ace8ba1f81c9f829b37cc4f2d@haskell.org> References: <046.f04aff3ace8ba1f81c9f829b37cc4f2d@haskell.org> Message-ID: <061.a84b40961c2ae41ba569afaef3e11ad2@haskell.org> #8576: Improve deriving error messages --------------------------------------------+------------------------------ Reporter: nomeata | Owner: nomeata Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type checker) | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Joachim Breitner ): In [changeset:"b3b88db924f39d83586f41cf35608bc4809b2a9a/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="b3b88db924f39d83586f41cf35608bc4809b2a9a" Update output: New error messages as per #8576 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 3 13:30:03 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Dec 2013 13:30:03 -0000 Subject: [GHC] #8576: Improve deriving error messages In-Reply-To: <046.f04aff3ace8ba1f81c9f829b37cc4f2d@haskell.org> References: <046.f04aff3ace8ba1f81c9f829b37cc4f2d@haskell.org> Message-ID: <061.2664e371e6172106a439938fb396581c@haskell.org> #8576: Improve deriving error messages --------------------------------------------+------------------------------ Reporter: nomeata | Owner: nomeata Type: feature request | Status: closed Priority: low | Milestone: Component: Compiler (Type checker) | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by nomeata): * status: new => closed * resolution: => fixed Comment: After some encouragement by SPJ, I did the refactoring, introducing `PredOrigin` and `ThetaOrigin` for constraints where we know something about where they came from. I do ''not'' use this new type in `FunDeps` yet, as suggested. Not because it is not possible (see branch `wip/T8692`), but because I could not test that code yet (see #8592). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 3 13:31:30 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Dec 2013 13:31:30 -0000 Subject: [GHC] #8592: FunDep error message regression In-Reply-To: <046.0e5c71777ac391c49229f8cb6d6cafaa@haskell.org> References: <046.0e5c71777ac391c49229f8cb6d6cafaa@haskell.org> Message-ID: <061.ead4fd81cf8c163323751b6291cad1e5@haskell.org> #8592: FunDep error message regression --------------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by nomeata): Branch `wip/T592` contains some refactoring of the `FunDeps` code that I don?t want to push to master before this issue is cleared, and the code tested. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 3 13:53:55 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Dec 2013 13:53:55 -0000 Subject: [GHC] #8592: FunDep error message regression In-Reply-To: <046.0e5c71777ac391c49229f8cb6d6cafaa@haskell.org> References: <046.0e5c71777ac391c49229f8cb6d6cafaa@haskell.org> Message-ID: <061.21e44d0c64783b6f40ac464eb7836856@haskell.org> #8592: FunDep error message regression --------------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by nomeata): More examples at http://www.haskell.org/pipermail/haskell- cafe/2008-December/052093.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 3 15:10:40 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Dec 2013 15:10:40 -0000 Subject: [GHC] #7307: Share top-level code for strings In-Reply-To: <046.a08650f8cdd36d5e1fecd64b2886fdde@haskell.org> References: <046.a08650f8cdd36d5e1fecd64b2886fdde@haskell.org> Message-ID: <061.5f7cd1f208bebb23e82767226db7ef68@haskell.org> #7307: Share top-level code for strings -------------------------------------+------------------------------------ Reporter: simonpj | Owner: parcs Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by parcs): * owner: => parcs Comment: I will try to do this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 3 16:31:31 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Dec 2013 16:31:31 -0000 Subject: [GHC] #8593: vector is being built even with `--no-dph` Message-ID: <046.299b1f7d2da2e7b67d43549a9011b54e@haskell.org> #8593: vector is being built even with `--no-dph` ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Build System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I usually use `./sync-all --no-dph get` to speed up things a bit. But packages `vector`, `primitive` and `random` are still being pulled (by virtue of being submodules), and then built. It would be nice if the build system would build them only if `libraries/dph` is available, or have another way of making them optional. (Potentially obsolete once #8545 is done.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 3 16:42:04 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Dec 2013 16:42:04 -0000 Subject: [GHC] #8592: FunDep error message regression In-Reply-To: <046.0e5c71777ac391c49229f8cb6d6cafaa@haskell.org> References: <046.0e5c71777ac391c49229f8cb6d6cafaa@haskell.org> Message-ID: <061.f940872ed3f38987729b23998a7bcb71@haskell.org> #8592: FunDep error message regression --------------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by nfrisby): My 2 cents: the error message mentioning functional dependencies is far more informative than the one just saying there's no instance for C Integer String. So, in my opinion, the change that prompted this ticket is indeed a regression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 3 16:51:17 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Dec 2013 16:51:17 -0000 Subject: [GHC] #8006: Asynchronous exception rethrown synchronously inside runStmt In-Reply-To: <044.dbb6774c6c740ebcfa8a0bafc038f76d@haskell.org> References: <044.dbb6774c6c740ebcfa8a0bafc038f76d@haskell.org> Message-ID: <059.6e1ed2bab76efee6d2950ac190843d01@haskell.org> #8006: Asynchronous exception rethrown synchronously inside runStmt -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Edsko de Vries ): In [changeset:"586bc85538cf12048137c2693da7c9fe3ca481ef/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="586bc85538cf12048137c2693da7c9fe3ca481ef" Mask async exceptions in forkM_ See #8006 for the reason why. This is not a fix as such; more of a workaround. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 3 17:42:34 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Dec 2013 17:42:34 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.569cad2c2c6ac003225162bd58355861@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by nomeata): Run nofib the first time, mixed results: {{{ binary-trees -1.3% +0.6% +7.7% +7.5% +0.0% hidden -1.3% -0.5% -0.3% -0.5% +0.0% mandel -1.2% -9.2% 0.10 0.10 +0.0% nucleic2 -1.0% -2.6% 0.11 0.11 +0.0% reverse-complem -1.3% +4.9% 0.21 0.22 +0.0% -------------------------------------------------------------------------------- Min -1.4% -9.2% -6.3% -6.6% -4.5% Max -1.0% +4.9% +7.7% +7.5% +0.0% Geometric Mean -1.3% -0.0% +0.5% +0.6% -0.1% }}} The gain in mandel seems to come from a a few more unboxed results in `Data.Complex`, in particular the return types of `$w$sphase` and `$w$smagnitued` turns from `Double` to `Double#` (and likewise the `Float`-specializations). And why the new chance for that? Because `$fFloatingComplex` (which is a CAF for `D# 0.0`) and other constants are inlined (and thus no longer shared). Not sure why that part changed, and it seems that this is not related to ''nested''CPR... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 3 21:40:08 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Dec 2013 21:40:08 -0000 Subject: [GHC] #8592: FunDep error message regression In-Reply-To: <046.0e5c71777ac391c49229f8cb6d6cafaa@haskell.org> References: <046.0e5c71777ac391c49229f8cb6d6cafaa@haskell.org> Message-ID: <061.6c81f6eea15e98e9b1dabd9e514dd49c@haskell.org> #8592: FunDep error message regression --------------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by nomeata): More examples at http://www.haskell.org/pipermail/ghc- devs/2013-December/003396.html (Collecting these links here because I want to ensure they will enter the testsuite.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 3 22:37:47 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Dec 2013 22:37:47 -0000 Subject: [GHC] #8589: Bad choice of loop breaker with INLINABLE/INLINE In-Reply-To: <052.029d6667ad632c5148f8f98b3c4c0bd3@haskell.org> References: <052.029d6667ad632c5148f8f98b3c4c0bd3@haskell.org> Message-ID: <067.05da394c9cd52c51818e319ed75a9bb1@haskell.org> #8589: Bad choice of loop breaker with INLINABLE/INLINE --------------------------------------------+------------------------------ Reporter: NickSmallbone | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by carter): I may have a nontrivial example of a related problem in INLINE/INLINEABLE + mutually recursive functions, i'll try to reconstruct it and add it to this ticket if i can reproduce the problem in HEAD -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 4 05:18:20 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Dec 2013 05:18:20 -0000 Subject: [GHC] #8594: sysctl name "hw.ncpu" (HW_NCPU) is deprecated in Mac OS X Message-ID: <043.14751a04063e97452853ca5e57a712e1@haskell.org> #8594: sysctl name "hw.ncpu" (HW_NCPU) is deprecated in Mac OS X ------------------------------------+--------------------------------- Reporter: kseo | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- According to the OS X man page for sysctl(https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man3/sysctlbyname.3.html), HW_NCPU used by the current implementation of getNumberOfProcessors() is deprecated. Instead, Mac OS X provides the following 4 options: * hw.physicalcpu: The number of physical processors available in the current power management mode. * hw.physicalcpu_max: The maximum number of physical processors that could be available this boot. * hw.logicalcpu: The number of logical processors available in the current power management mode. * hw.logicalcpu_max: The maximum number of logical processors that could be available this boot. I am not sure which one fits best to GHC runtime. Any idea? sysconf implementation of getNumberOfProcessors() seems to prefer _SC_NPROCESSORS_ONLN to _SC_NPROCESSORS_CONF when both are defined. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 4 05:42:46 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Dec 2013 05:42:46 -0000 Subject: [GHC] #3625: GHCI doesn't work with dtrace on OS X In-Reply-To: <041.efc4099a4816c68174bfd27196e4a151@haskell.org> References: <041.efc4099a4816c68174bfd27196e4a151@haskell.org> Message-ID: <056.6d0d299a30a22a0cdd3fa3643419fa88@haskell.org> #3625: GHCI doesn't work with dtrace on OS X ---------------------------------+------------------------------------ Reporter: rl | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: GHCi | Version: 6.10.4 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Changes (by carter): * cc: hvr (added) Comment: is this resolved with ghc 7.7 head? Has anyone tested dtrce with head? if not i'll try to find the time to test it out soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 4 06:08:02 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Dec 2013 06:08:02 -0000 Subject: [GHC] #8594: sysctl name "hw.ncpu" (HW_NCPU) is deprecated in Mac OS X In-Reply-To: <043.14751a04063e97452853ca5e57a712e1@haskell.org> References: <043.14751a04063e97452853ca5e57a712e1@haskell.org> Message-ID: <058.fdb61e5e6b86587d2f0f9c96822c2dd7@haskell.org> #8594: sysctl name "hw.ncpu" (HW_NCPU) is deprecated in Mac OS X -----------------------------------+------------------------------------ Reporter: kseo | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+------------------------------------ Comment (by carter): I think logicalcpu counts the number of hyperthreaded cores, and physicalcpu is the number of cores (ignoring hyperthreading), which should be half that number. I checked this on my macbook air (which has 2 cores, but 4 via hyper threading) {{{ carter repoScratcher/ghc ?master? ? sysctl hw.physicalcpu hw.physicalcpu: 2 carter repoScratcher/ghc ?master? ? sysctl hw.logicalcpu hw.logicalcpu: 4 }}} I think the _max variants is because using the Instruments App, you can tell OS X to disable hardware multithreading/ adjust the number of cores the OS scheduler sees. I just disabled the hyperthreading using Instruments, and now i get {{{ carter repoScratcher/ghc ?master? ? sysctl hw.logicalcpu hw.logicalcpu: 2 }}} So i think the not max variants make sense, namely hw.logicalcpu , because that actually reflects the number of logical cores the OS sees. for general use, using the hyperthreaded cores is probably the right default, rather than not. Admittedly, on parallel computations that are memory bound, hyperthreading can either boon or a curse, and perhaps this is worth benchmarking! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 4 07:38:10 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Dec 2013 07:38:10 -0000 Subject: [GHC] #3384: Add HsSyn prettyprinter tests In-Reply-To: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> References: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> Message-ID: <059.39f41407d432e38e7cd7736a30377182@haskell.org> #3384: Add HsSyn prettyprinter tests -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Test Suite | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by kseo): * failure: => None/Unknown Comment: I'd like to work on this task as my first patch to GHC. I think the idea suggested by dfranke in #1966 is a good starting point. Take some large Haskell projects and: 1. Parse them 1. Pretty-print them 1. Reparse the output 1. Pretty-print again and verify that step 3 succeeds and the outputs of steps 2 and 4 match. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 4 07:39:33 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Dec 2013 07:39:33 -0000 Subject: [GHC] #3384: Add HsSyn prettyprinter tests In-Reply-To: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> References: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> Message-ID: <059.45d37dda5cccf1e3c6c76ab5b0cb7971@haskell.org> #3384: Add HsSyn prettyprinter tests -------------------------------------+------------------------------------ Reporter: igloo | Owner: kseo Type: task | Status: new Priority: normal | Milestone: _|_ Component: Test Suite | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by kseo): * owner: => kseo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 4 08:15:58 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Dec 2013 08:15:58 -0000 Subject: [GHC] #8592: FunDep error message regression In-Reply-To: <046.0e5c71777ac391c49229f8cb6d6cafaa@haskell.org> References: <046.0e5c71777ac391c49229f8cb6d6cafaa@haskell.org> Message-ID: <061.2e8174bc5bd25ebd523d3f7da6b759b8@haskell.org> #8592: FunDep error message regression --------------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by nomeata): Bah, I need more sleep. Just because the test suite does not contain any examples of the error message now, it does not mean that it did not have in the past. And indeed ? `git log -G` to the rescue ? there are examples like `FD3`, and commit [69f0da5ddaf90a5fa9eec406ec96a0256428fed9/testsuite] (April 2013, SPJ) updated the output to what it is now, without the ?When using functional dependencies to combine? message. Therefore I conclude that the change of output is deliberate, and this bug is just about finding out whether that kind of error message can still occur (in which case a testcase would be nice), or if it is dead code that should be removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 4 08:54:37 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Dec 2013 08:54:37 -0000 Subject: [GHC] #8590: Reduce code size of CAFs In-Reply-To: <044.abfe0e6f5cd5b3fe2a2632f41576ec73@haskell.org> References: <044.abfe0e6f5cd5b3fe2a2632f41576ec73@haskell.org> Message-ID: <059.c013c5a3c9180b8edba16b2be5a8085b@haskell.org> #8590: Reduce code size of CAFs -------------------------------------+------------------------------------ Reporter: parcs | Owner: parcs Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Looks great to me. Could you bear to write a `Note [How CAFs are compiled]` in `StgCmmBind` (and perhaps cross-refer from `Storage.c`) so that there is a little writeup of the logic involved. Or maybe the Note belongs somewhere else. It would be good to cover (briefly) * What code we generate for CAFs * How and why they are reverted * What the CAF list is and why it is needed. Alternatively, elaborate this page [wiki:Commentary/Rts/Storage/GC/CAFs], and cross-refer to it from the code. While it's all fresh in your mind. Doubtless you had to infer lots of stuff from the code! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 4 09:51:51 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Dec 2013 09:51:51 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.b955c65d71e525eac32064ffcb3a91ab@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: nomeata Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by nomeata): * owner: => nomeata Comment: Interesting corner case: With nested CPR enabled, `GHC.TopHandler` in base fails to compile with: {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.7.20131203 for x86_64-unknown-linux): mkWWcpr: non-algebraic or open body type a{tv a28d} [tv] but CPR type tm1() }}} The problem is this code: {{{ #!haskell case {__pkg_ccall_GC base shutdownHaskellAndExit GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld #)}_d2VI 255 ds_d2VF eta_XG of _ [Occ=Dead, Dmd=] { (# ds_d2VG [OS=OneShot] #) -> (# ds_d2VG, GHC.Tuple.() #) }}} stemming from {{{ #!haskell foreign import ccall "shutdownHaskellAndSignal" shutdownHaskellAndSignal :: CInt -> CInt -> IO () }}} which then is `unsafeCoerce#`?ed to `a`, with note explanation {{{ -- we have to use unsafeCoerce# to get the 'IO a' result type, since the -- compiler doesn't let us declare that as the result type of a foreign export. }}} There are a few ways to attack this issue: 1. We allow `a` in the return type of a foreign export (but maybe overkill to do that just for this code). 2. We try to forget CPR information when things pass through `unsafeCoerce#` (but that is just a {{{`cast`}}} in Core, and may be hard to detect reliably. Maybe every coercion that has a `UnivCo representational` inside?) 3. We re-write that code in base, e.g. instead of `unsafeCoerce` use `... >> error "I?m still alive?"`. 4. We simply turn the `panic` into a warning. I guess 2. makes most sense, because we don?t want other instances of `unsafeCoerce#` to cause this error either. For now I?ll do 4, to not get stuck compiling base. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 4 10:29:17 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Dec 2013 10:29:17 -0000 Subject: [GHC] #8595: add fusion RULES for mapMaybe Message-ID: <043.a2cc64b16619e5e84df1c2d2b14cb703@haskell.org> #8595: add fusion RULES for mapMaybe ------------------------------------+------------------------------------- Reporter: akio | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Currently mapMaybe does not fuse at all. The attached patch implements necessary rules for fold/build fusion in both sides (the result and the second argument) to happen. When fusion does not happen, the function should behave exactly the same as before. This proposal has gone through a discussion in the libraries mailing list: http://www.haskell.org/pipermail/libraries/2013-November/021640.html [Note that the subject of the e-mail thread is wrong, it should mention "Data.Maybe.mapMaybe", not "Data.Map.mapMaybe"] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 4 10:29:58 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Dec 2013 10:29:58 -0000 Subject: [GHC] #8595: add fusion RULES for mapMaybe In-Reply-To: <043.a2cc64b16619e5e84df1c2d2b14cb703@haskell.org> References: <043.a2cc64b16619e5e84df1c2d2b14cb703@haskell.org> Message-ID: <058.d0ea45afc59385137007ad7c8b885672@haskell.org> #8595: add fusion RULES for mapMaybe -------------------------------------+------------------------------------ Reporter: akio | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by akio): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 4 10:49:15 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Dec 2013 10:49:15 -0000 Subject: [GHC] #8590: Reduce code size of CAFs In-Reply-To: <044.abfe0e6f5cd5b3fe2a2632f41576ec73@haskell.org> References: <044.abfe0e6f5cd5b3fe2a2632f41576ec73@haskell.org> Message-ID: <059.44eb203b1c6ebea4b1413b6c8bd676d5@haskell.org> #8590: Reduce code size of CAFs -------------------------------------+------------------------------------ Reporter: parcs | Owner: parcs Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): Simon, this is pretty well documented already in `Storage.c`, all the points you mention are already covered. In fact some of it is *also* documented in `StgCmmBind`. I suggest: * remove the comments in `StgCmmBind`, replace with a pointer to `Storage.c`. Multiple comments describing the same thing are bad, because when making changes we'll tend to only update one of them. * edit the comments in `Storage.c` to bring them up to date with the changes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 4 10:53:21 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Dec 2013 10:53:21 -0000 Subject: [GHC] #8006: Asynchronous exception rethrown synchronously inside runStmt In-Reply-To: <044.dbb6774c6c740ebcfa8a0bafc038f76d@haskell.org> References: <044.dbb6774c6c740ebcfa8a0bafc038f76d@haskell.org> Message-ID: <059.b3c1a9b9b36f18d9c93557a37dd0ce73@haskell.org> #8006: Asynchronous exception rethrown synchronously inside runStmt -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): If that fixes the bug, I'm ok with closing this ticket. I doubt we're going to pursue a more "correct" fix, unless any problems arise with this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 4 10:59:07 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Dec 2013 10:59:07 -0000 Subject: [GHC] #8006: Asynchronous exception rethrown synchronously inside runStmt In-Reply-To: <044.dbb6774c6c740ebcfa8a0bafc038f76d@haskell.org> References: <044.dbb6774c6c740ebcfa8a0bafc038f76d@haskell.org> Message-ID: <059.90f13cc9ac985d756680f451b8f23102@haskell.org> #8006: Asynchronous exception rethrown synchronously inside runStmt -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by edsko): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 4 11:11:47 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Dec 2013 11:11:47 -0000 Subject: [GHC] #8595: add fusion RULES for mapMaybe In-Reply-To: <043.a2cc64b16619e5e84df1c2d2b14cb703@haskell.org> References: <043.a2cc64b16619e5e84df1c2d2b14cb703@haskell.org> Message-ID: <058.f9f16cd7f9a33e0c922c638c39ae3441@haskell.org> #8595: add fusion RULES for mapMaybe -------------------------------------+------------------------------------ Reporter: akio | Owner: nomeata Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * owner: => nomeata Comment: I?ll validate and push this later today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 4 11:21:41 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Dec 2013 11:21:41 -0000 Subject: [GHC] #8590: Reduce code size of CAFs In-Reply-To: <044.abfe0e6f5cd5b3fe2a2632f41576ec73@haskell.org> References: <044.abfe0e6f5cd5b3fe2a2632f41576ec73@haskell.org> Message-ID: <059.12f1c2631c7a2a87a4f7782d3d2a03a3@haskell.org> #8590: Reduce code size of CAFs -------------------------------------+------------------------------------ Reporter: parcs | Owner: parcs Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Great! Sorry I was just looking at the patch itself. Indeed a pointer from (the appropriate point in) `StgCmmBind` to the detailed description in `Storage.c` would be good. Also from the wiki page I referenced. Thanks parcs Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 4 13:04:18 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Dec 2013 13:04:18 -0000 Subject: [GHC] #8595: add fusion RULES for mapMaybe In-Reply-To: <043.a2cc64b16619e5e84df1c2d2b14cb703@haskell.org> References: <043.a2cc64b16619e5e84df1c2d2b14cb703@haskell.org> Message-ID: <058.4c8d7d39a1f6f51ad2afc834acc66b69@haskell.org> #8595: add fusion RULES for mapMaybe -------------------------------------+------------------------------------ Reporter: akio | Owner: nomeata Type: feature request | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * status: patch => closed * resolution: => fixed Comment: Thx, pushed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 4 13:15:00 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Dec 2013 13:15:00 -0000 Subject: [GHC] #3625: GHCI doesn't work with dtrace on OS X In-Reply-To: <041.efc4099a4816c68174bfd27196e4a151@haskell.org> References: <041.efc4099a4816c68174bfd27196e4a151@haskell.org> Message-ID: <056.318c5c55605ddbca5059e39c9a0c5ee7@haskell.org> #3625: GHCI doesn't work with dtrace on OS X ---------------------------------+------------------------------------ Reporter: rl | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: GHCi | Version: 6.10.4 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by lelf): {{{ Betty:cbits lelf$ sudo dtrace -i 'demo- trace{printf("%s",copyinstr(arg0))}' dtrace: description 'demo-trace' matched 1 probe CPU ID FUNCTION:NAME 0 2547 demo_trace:demo-trace rzzzz 1 2547 demo_trace:demo-trace foo 0 2547 demo_trace:demo-trace bar 0 2547 demo_trace:demo-trace bzzzzz }}} Seems to work -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 4 13:19:16 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Dec 2013 13:19:16 -0000 Subject: [GHC] #5821: SPECIALISE fails with a cryptic warning In-Reply-To: <041.0c42da3432a831cfdfec52f79b870abb@haskell.org> References: <041.0c42da3432a831cfdfec52f79b870abb@haskell.org> Message-ID: <056.6b60197533c1db77ccca0bfc34107660@haskell.org> #5821: SPECIALISE fails with a cryptic warning -------------------------------------------------+------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect warning at | Unknown/Multiple compile-time | Difficulty: Test Case: | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by mikhail.vorozhtsov): * cc: mikhail.vorozhtsov@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 4 16:56:22 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Dec 2013 16:56:22 -0000 Subject: [GHC] #8592: FunDep error message regression In-Reply-To: <046.0e5c71777ac391c49229f8cb6d6cafaa@haskell.org> References: <046.0e5c71777ac391c49229f8cb6d6cafaa@haskell.org> Message-ID: <061.83dd68ac312a1736ac6e9e93b8bd7c1a@haskell.org> #8592: FunDep error message regression --------------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Joachim Breitner ): In [changeset:"9d7cbbcf625bc103d9fd086e9fcf99cb5c4b56ea/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9d7cbbcf625bc103d9fd086e9fcf99cb5c4b56ea" Remove code that generates FunDep error message context as it seems that this code is now dead (due to [Dropping derived constraints]) (See #8592) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 4 16:56:39 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Dec 2013 16:56:39 -0000 Subject: [GHC] #8592: FunDep error message regression In-Reply-To: <046.0e5c71777ac391c49229f8cb6d6cafaa@haskell.org> References: <046.0e5c71777ac391c49229f8cb6d6cafaa@haskell.org> Message-ID: <061.c4888e810cdb2e14a477a5590dd3e5d6@haskell.org> #8592: FunDep error message regression --------------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by nomeata): * status: new => closed * resolution: => fixed Comment: As discussed with SPJ it seems that the such error messages no longer occur. I have removed the code that generates them, closing this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 4 17:25:58 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Dec 2013 17:25:58 -0000 Subject: [GHC] #8589: Bad choice of loop breaker with INLINABLE/INLINE In-Reply-To: <052.029d6667ad632c5148f8f98b3c4c0bd3@haskell.org> References: <052.029d6667ad632c5148f8f98b3c4c0bd3@haskell.org> Message-ID: <067.e18a89bfe1dde419aea447654baa7905@haskell.org> #8589: Bad choice of loop breaker with INLINABLE/INLINE --------------------------------------------+------------------------------ Reporter: NickSmallbone | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): '''Explanation of what is happening.''' * Remember that each `Id` has one, and only one, inlining attached to it. * With INLINABLE/INLINE, the `pair`'s inlining is used to store the original RHS. * But since the group is recursive, `pair` is chosen as loop breaker, and never gets inlined. Why does it work without an INLINE pragma? Because we don't snapshot the original RHS we are free to optimise it, which we do by "floating out" some local let bindings, thus exposing the pair. And we are careful never to choose a visible pair as a loop breaker unless we absolutely have to. '''What to do'''. I'm now pretty sure that INLINEABE should really be "SPECIALISABLE", and should be stored quite separately from the Id's inlining. Then they would not get in each others way. See #5928 for another example. INLINE is a bit less obvious. The simple cases are already fine: * For non-recursive functions, if you say INLINE, you really mean to inline it, so it seems stupid to keep a separate snapshot. * Recursive functions never inline anyway, so an INLINE pragma is stupid. A recursive ''group'' with INLINE is tricky,and that is the case here. I'm still thinking about how it should go. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 4 18:49:05 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Dec 2013 18:49:05 -0000 Subject: [GHC] #8590: Reduce code size of CAFs In-Reply-To: <044.abfe0e6f5cd5b3fe2a2632f41576ec73@haskell.org> References: <044.abfe0e6f5cd5b3fe2a2632f41576ec73@haskell.org> Message-ID: <059.4c5c2ef9ccfa762a1ad62412a7c91d6e@haskell.org> #8590: Reduce code size of CAFs -------------------------------------+------------------------------------ Reporter: parcs | Owner: parcs Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by parcs): Thanks for the comments. I've deduplicated and updated the CAF documentation in a followup patch. In the meantime, I noticed an oversight in the original patch. `lockCAF()` was not setting the profiling header of the newly-allocated blackhole. To fix this, I changed the following line {{{ #!c bh->header.info = &stg_CAF_BLACKHOLE_info; }}} to {{{ #!c SET_HDR(bh, &stg_CAF_BLACKHOLE_info, caf->header.prof.ccs); }}} which has the blackhole inherit the CCS from the respective CAF, equivalent to what the old code did. I'm going to commit this patch now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 4 18:49:26 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Dec 2013 18:49:26 -0000 Subject: [GHC] #8590: Reduce code size of CAFs In-Reply-To: <044.abfe0e6f5cd5b3fe2a2632f41576ec73@haskell.org> References: <044.abfe0e6f5cd5b3fe2a2632f41576ec73@haskell.org> Message-ID: <059.c20e03c2a41b89db8e65ce4df8736fef@haskell.org> #8590: Reduce code size of CAFs -------------------------------------+------------------------------------ Reporter: parcs | Owner: parcs Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Patrick Palka ): In [changeset:"55c703b8fdb040c51bf8784beb3dc02332db417a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="55c703b8fdb040c51bf8784beb3dc02332db417a" Move the allocation of CAF blackholes into 'newCAF' (#8590) We now do the allocation of the blackhole indirection closure inside the RTS procedure 'newCAF' instead of generating the allocation code inline in the closure body of each CAF. This slightly decreases code size in modules with a lot of CAFs. As a result of this change, for example, the size of DynFlags.o drops by ~60KB and HsExpr.o by ~100KB. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 4 18:49:26 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Dec 2013 18:49:26 -0000 Subject: [GHC] #8590: Reduce code size of CAFs In-Reply-To: <044.abfe0e6f5cd5b3fe2a2632f41576ec73@haskell.org> References: <044.abfe0e6f5cd5b3fe2a2632f41576ec73@haskell.org> Message-ID: <059.ecb4063828bc54cadc629c038830c4ee@haskell.org> #8590: Reduce code size of CAFs -------------------------------------+------------------------------------ Reporter: parcs | Owner: parcs Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Patrick Palka ): In [changeset:"fe68ad50f3fa7d73df691f9fd9decd17a72b8b46/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="fe68ad50f3fa7d73df691f9fd9decd17a72b8b46" Update and deduplicate the comments on CAF management (#8590) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 4 19:27:02 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Dec 2013 19:27:02 -0000 Subject: [GHC] #7307: Share top-level code for strings In-Reply-To: <046.a08650f8cdd36d5e1fecd64b2886fdde@haskell.org> References: <046.a08650f8cdd36d5e1fecd64b2886fdde@haskell.org> Message-ID: <061.b68ee671a60851cb02ee4893e27ff33d@haskell.org> #7307: Share top-level code for strings -------------------------------------+------------------------------------ Reporter: simonpj | Owner: parcs Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by parcs): Here's an experimental patch that achieves what's described in the ticket. It creates a new closure type, `StgTopUnpack` along with a new info table `stg_TOP_UNPACK_info`. All top-level strings are emitted as 4-word thunks (all thunks need to have the same closure representation), with the address of the static string being stored in the 2nd word. Miraculously, the code works. Binary sizes drop a further ~(2-3)% (on top of size reduction from #8590) and GHC can still bootstrap itself. But there are a few issues that I am having trouble with: 1. I am not sure what closure flags `TOP_UNPACK` should have. 2. I do not think entry code for `TOP_UNPACK` is correct. For starters, I mixed high-level Cmm (argument lists) with low-level Cmm (use of `Sp`). But the whole thing is likely wrong. Could somebody take a quick look? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 4 22:34:28 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Dec 2013 22:34:28 -0000 Subject: [GHC] #7307: Share top-level code for strings In-Reply-To: <046.a08650f8cdd36d5e1fecd64b2886fdde@haskell.org> References: <046.a08650f8cdd36d5e1fecd64b2886fdde@haskell.org> Message-ID: <061.fc04ba373a430c794747f7a49e1b7321@haskell.org> #7307: Share top-level code for strings -------------------------------------+------------------------------------ Reporter: simonpj | Owner: parcs Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): Very cool! So this would also be possibly part of a first step towards generally "statically constructing/evaluating" small constant data structures at compile time rather than computing them? I'm not familiar with that piece of GHC as yet, but i'll take a wee look at the patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 4 22:47:26 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Dec 2013 22:47:26 -0000 Subject: [GHC] #8589: Bad choice of loop breaker with INLINABLE/INLINE In-Reply-To: <052.029d6667ad632c5148f8f98b3c4c0bd3@haskell.org> References: <052.029d6667ad632c5148f8f98b3c4c0bd3@haskell.org> Message-ID: <067.c2650dfe5d9316f10966268c80c8223f@haskell.org> #8589: Bad choice of loop breaker with INLINABLE/INLINE --------------------------------------------+------------------------------ Reporter: NickSmallbone | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by carter): @simon, so would that imply specializable would (then) be usable on functions that don't have any type class parameters? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 4 22:52:34 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Dec 2013 22:52:34 -0000 Subject: [GHC] #8589: Bad choice of loop breaker with INLINABLE/INLINE In-Reply-To: <052.029d6667ad632c5148f8f98b3c4c0bd3@haskell.org> References: <052.029d6667ad632c5148f8f98b3c4c0bd3@haskell.org> Message-ID: <067.de3010241383e8b0f4a7a0491d436d8a@haskell.org> #8589: Bad choice of loop breaker with INLINABLE/INLINE --------------------------------------------+------------------------------ Reporter: NickSmallbone | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): What would it mean to specialise a function with no type-class parameters. Example? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 4 23:00:16 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Dec 2013 23:00:16 -0000 Subject: [GHC] #8589: Bad choice of loop breaker with INLINABLE/INLINE In-Reply-To: <052.029d6667ad632c5148f8f98b3c4c0bd3@haskell.org> References: <052.029d6667ad632c5148f8f98b3c4c0bd3@haskell.org> Message-ID: <067.4d2db4706823a3692c569322b4630ae8@haskell.org> #8589: Bad choice of loop breaker with INLINABLE/INLINE --------------------------------------------+------------------------------ Reporter: NickSmallbone | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by carter): sorry, let me clarify, you said "INLINEABLE should really be like SPECIALIZABLE", so I'm asking you to sort of expand on what you mean, and how such a modified INLINEABLE would work on typeclass-free code (ie just a polymorphic function like apply :: (a -> b )-> a -> b ). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 4 23:43:13 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Dec 2013 23:43:13 -0000 Subject: [GHC] #7307: Share top-level code for strings In-Reply-To: <046.a08650f8cdd36d5e1fecd64b2886fdde@haskell.org> References: <046.a08650f8cdd36d5e1fecd64b2886fdde@haskell.org> Message-ID: <061.cf6e7ead2af409ae9d802583635fde37@haskell.org> #7307: Share top-level code for strings -------------------------------------+------------------------------------ Reporter: simonpj | Owner: parcs Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by parcs): Replying to [comment:4 carter]: > Very cool! So this would also be possibly part of a first step towards generally "statically constructing/evaluating" small constant data structures at compile time rather than computing them? I'm not familiar with that piece of GHC as yet, but i'll take a wee look at the patch. The `String` is still created at runtime. But the code that creates a heap object from the static object is no longer duplicated for each string literal in the module. (Hmm, I wonder whether this technique could be generalized for all CAFs, not just top-level strings...) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 5 00:16:56 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Dec 2013 00:16:56 -0000 Subject: [GHC] #8562: Builtin function __builtin___clear_cache is unavailable on GCC 4.2 In-Reply-To: <047.84726fd9ab3632509c55e16aa3ebee4d@haskell.org> References: <047.84726fd9ab3632509c55e16aa3ebee4d@haskell.org> Message-ID: <062.57ff768a34a91cd249a98947a9d83ae1@haskell.org> #8562: Builtin function __builtin___clear_cache is unavailable on GCC 4.2 --------------------------------------------+------------------------------ Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: GHC doesn't work at all | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8561 --------------------------------------------+------------------------------ Comment (by Austin Seipp ): In [changeset:"95854ca5276e3f4063ade7fe3a934bed46648270/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="95854ca5276e3f4063ade7fe3a934bed46648270" Use new flushExec implementation on all operating systems (#8562) An earlier patch fixes a bug in flushExec on linux only. This patch uses the fixed code on all operating systems. Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 5 00:17:43 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Dec 2013 00:17:43 -0000 Subject: [GHC] #8562: Builtin function __builtin___clear_cache is unavailable on GCC 4.2 In-Reply-To: <047.84726fd9ab3632509c55e16aa3ebee4d@haskell.org> References: <047.84726fd9ab3632509c55e16aa3ebee4d@haskell.org> Message-ID: <062.ef4352f6516de701111ec4ee9a1cb631@haskell.org> #8562: Builtin function __builtin___clear_cache is unavailable on GCC 4.2 --------------------------------------------+------------------------------ Reporter: heatsink | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: GHC doesn't work at all | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8561 --------------------------------------------+------------------------------ Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 5 00:18:25 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Dec 2013 00:18:25 -0000 Subject: [GHC] #8590: Reduce code size of CAFs In-Reply-To: <044.abfe0e6f5cd5b3fe2a2632f41576ec73@haskell.org> References: <044.abfe0e6f5cd5b3fe2a2632f41576ec73@haskell.org> Message-ID: <059.f0077e10cbf0a3f799d5852628791976@haskell.org> #8590: Reduce code size of CAFs -------------------------------------+------------------------------------ Reporter: parcs | Owner: parcs Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Thanks Patrick! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 5 01:14:23 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Dec 2013 01:14:23 -0000 Subject: [GHC] #7307: Share top-level code for strings In-Reply-To: <046.a08650f8cdd36d5e1fecd64b2886fdde@haskell.org> References: <046.a08650f8cdd36d5e1fecd64b2886fdde@haskell.org> Message-ID: <061.48a0da07fc5b774a0838514abcd65953@haskell.org> #7307: Share top-level code for strings -------------------------------------+------------------------------------ Reporter: simonpj | Owner: parcs Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ezyang): Yeah, this code is buggy. Here are the problems I can find from a quick pass: * TOP_UNPACK is declared to have a thunk-representation. In that case, it needs to use a `StgThunkHeader`, so that the extra padding required to allow for lock-less thunk update in multithreaded code. * Similarly, it should be given the THU and SRT flags. Since these thunks are emitted into the data section (i.e. are static data), they also need the static flag (like THUNK_STATIC). So really TOP_UNPACK is a bad name. * I am not sure this is a good idea, but it seems like this mechanism could be generalized to variadic THUNK_STATICs, which are essentially THUNK_STATIC but have some payload attached to the end. You don't even have to hard-code the infotable anymore. * The GC code is wrong; TOP_UNPACK should be handled like a THUNK_STATIC. * I know for a fact you're missing this case from a number of other giant switch statements in the RTS. Do a grep. * The generated info table never pushes an update frame to adjust itself. So what happens when a reference to a TOP_UNPACK is inside generated code? I think you will end up repeatedly unpacking the string, though I am not 100% sure here. * As for whether or not your C-- is right, you should double-check it with the old C-- we were generating for handling unpacking per thunk. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 5 03:46:31 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Dec 2013 03:46:31 -0000 Subject: [GHC] #8594: sysctl name "hw.ncpu" (HW_NCPU) is deprecated in Mac OS X In-Reply-To: <043.14751a04063e97452853ca5e57a712e1@haskell.org> References: <043.14751a04063e97452853ca5e57a712e1@haskell.org> Message-ID: <058.eb966b9bdd0b688fd4eb84ed19dd8a27@haskell.org> #8594: sysctl name "hw.ncpu" (HW_NCPU) is deprecated in Mac OS X -----------------------------------+------------------------------------ Reporter: kseo | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+------------------------------------ Comment (by kseo): It seems hw.ncpu is equivalent to hw.logicalcpu. {{{ kseo at com100ui-MacBook-Pro:~> sysctl hw.ncpu hw.ncpu: 4 }}} {{{ kseo at com100ui-MacBook-Pro:~> sysctl hw.logicalcpu hw.logicalcpu: 4 }}} {{{ kseo at com100ui-MacBook-Pro:~> sysctl hw.physicalcpu hw.physicalcpu: 2 }}} Does GHC have a benchmark suite to measure the impact of this change? If not, we can fallback to hw.logicalcpu if hw.ncpu is not available. This at least preserves the current behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 5 04:00:08 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Dec 2013 04:00:08 -0000 Subject: [GHC] #7962: "ghc -e " should return non-zero exit status In-Reply-To: <046.b219f88aa753aa2b186103bc8ef072c0@haskell.org> References: <046.b219f88aa753aa2b186103bc8ef072c0@haskell.org> Message-ID: <061.0381ac3dde14a127deb42aa93bca965b@haskell.org> #7962: "ghc -e " should return non-zero exit status ------------------------------------+------------------------------------ Reporter: timmaxw | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"47024b63835e2bc238f88e3e1a5b5927a850e74c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="47024b63835e2bc238f88e3e1a5b5927a850e74c" Made ghc -e have a nonzero exit code upon failure (Trac #7962 ) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 5 04:34:54 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Dec 2013 04:34:54 -0000 Subject: [GHC] #7962: "ghc -e " should return non-zero exit status In-Reply-To: <046.b219f88aa753aa2b186103bc8ef072c0@haskell.org> References: <046.b219f88aa753aa2b186103bc8ef072c0@haskell.org> Message-ID: <061.214f144a575a1312cf5ce8869e097369@haskell.org> #7962: "ghc -e " should return non-zero exit status ------------------------------------+------------------------------------ Reporter: timmaxw | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"69f60722eabcce8283a4270b8d3aff712c8d462a/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="69f60722eabcce8283a4270b8d3aff712c8d462a" Add new ghc-e/should_fail test suite Also add a basic test for #7962. Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 5 04:35:13 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Dec 2013 04:35:13 -0000 Subject: [GHC] #8580: Integer size mismatch errors In-Reply-To: <047.d4333db31befff4b75ede8d807b689c8@haskell.org> References: <047.d4333db31befff4b75ede8d807b689c8@haskell.org> Message-ID: <062.662b6ebdd501ba750415caf2c2f99c91@haskell.org> #8580: Integer size mismatch errors -------------------------------------+------------------------------------- Reporter: heatsink | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86 Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 5 04:35:24 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Dec 2013 04:35:24 -0000 Subject: [GHC] #7962: "ghc -e " should return non-zero exit status In-Reply-To: <046.b219f88aa753aa2b186103bc8ef072c0@haskell.org> References: <046.b219f88aa753aa2b186103bc8ef072c0@haskell.org> Message-ID: <061.cab523d0c2cc9e95f6e785e2414082c8@haskell.org> #7962: "ghc -e " should return non-zero exit status ------------------------------------+------------------------------------ Reporter: timmaxw | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.6.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Done, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 5 05:31:45 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Dec 2013 05:31:45 -0000 Subject: [GHC] #8594: sysctl name "hw.ncpu" (HW_NCPU) is deprecated in Mac OS X In-Reply-To: <043.14751a04063e97452853ca5e57a712e1@haskell.org> References: <043.14751a04063e97452853ca5e57a712e1@haskell.org> Message-ID: <058.fd17a0976d8d8e18cb2c17ec97c47230@haskell.org> #8594: sysctl name "hw.ncpu" (HW_NCPU) is deprecated in Mac OS X -----------------------------------+------------------------------------ Reporter: kseo | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+------------------------------------ Comment (by carter): benchmark suite for which? using the physical cpu count? thats be like using -N2 rather than -N4 (as our default value of -N). In performance sensitive applications, using the physical core count can sometimes be a win because of better cache behavior, but defualting to using the logical cpu count is the right default for general purpose applications. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 5 06:07:06 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Dec 2013 06:07:06 -0000 Subject: [GHC] #8594: sysctl name "hw.ncpu" (HW_NCPU) is deprecated in Mac OS X In-Reply-To: <043.14751a04063e97452853ca5e57a712e1@haskell.org> References: <043.14751a04063e97452853ca5e57a712e1@haskell.org> Message-ID: <058.af873d99f876a70b7f026d08b20ba54b@haskell.org> #8594: sysctl name "hw.ncpu" (HW_NCPU) is deprecated in Mac OS X -----------------------------------+------------------------------------ Reporter: kseo | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+------------------------------------ Comment (by carter): feel free to benchmark though, but I don't think it likely matters -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 5 07:29:19 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Dec 2013 07:29:19 -0000 Subject: [GHC] #8594: sysctl name "hw.ncpu" (HW_NCPU) is deprecated in Mac OS X In-Reply-To: <043.14751a04063e97452853ca5e57a712e1@haskell.org> References: <043.14751a04063e97452853ca5e57a712e1@haskell.org> Message-ID: <058.9377a6912456fe1795f5469b05d0f388@haskell.org> #8594: sysctl name "hw.ncpu" (HW_NCPU) is deprecated in Mac OS X -----------------------------------+------------------------------------ Reporter: kseo | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+------------------------------------ Comment (by kseo): I've attached a patch to use hw.logicalcpu in OS X. FreeBSD still uses "hw.ncpu", so I split the guard. This patch does not change the behavior because hw.ncpu also returns the logical cpu count. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 5 08:31:20 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Dec 2013 08:31:20 -0000 Subject: [GHC] #8577: Polymorphism and typed TH In-Reply-To: <047.42718c612858c204c7b6a7535f3af16b@haskell.org> References: <047.42718c612858c204c7b6a7535f3af16b@haskell.org> Message-ID: <062.cb7c0dc11930abbe0f378884e5b84d07@haskell.org> #8577: Polymorphism and typed TH -------------------------------------+------------------------------------ Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"8b642debfabe00377f47d461d31d70636bf0fce3/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8b642debfabe00377f47d461d31d70636bf0fce3" Typecheck typed TH splices properly (fix Trac #8577) This was an egregious error. If e :: T (Q ty1) then when we have the splice $e :: ty2 we must ensure that ty1~ty2 before we even think about running the splice! I took the opportunity to remove the dead-code tcSpliceDecls altogether. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 5 08:31:20 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Dec 2013 08:31:20 -0000 Subject: [GHC] #7396: Improve "parse error on input `$'" when TemplateHaskell PRAGMA not declared In-Reply-To: <045.6c29ee0e9781fd9f6a3d1232f4250abc@haskell.org> References: <045.6c29ee0e9781fd9f6a3d1232f4250abc@haskell.org> Message-ID: <060.87a737655dedfba119169f52b65006a3@haskell.org> #7396: Improve "parse error on input `$'" when TemplateHaskell PRAGMA not declared ----------------------------------------+--------------------------- Reporter: ydewit | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 7.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by Simon Peyton Jones ): In [changeset:"0f2a20bc882a918d39219b045a8db1ac7d9354fc/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0f2a20bc882a918d39219b045a8db1ac7d9354fc" Suggest TemplateHaskell after encountering a naked top-level expression Helps fix #7396 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 5 08:31:20 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Dec 2013 08:31:20 -0000 Subject: [GHC] #7396: Improve "parse error on input `$'" when TemplateHaskell PRAGMA not declared In-Reply-To: <045.6c29ee0e9781fd9f6a3d1232f4250abc@haskell.org> References: <045.6c29ee0e9781fd9f6a3d1232f4250abc@haskell.org> Message-ID: <060.15b5742ec5e9b6c9cc8e1a833399332d@haskell.org> #7396: Improve "parse error on input `$'" when TemplateHaskell PRAGMA not declared ----------------------------------------+--------------------------- Reporter: ydewit | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 7.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by Simon Peyton Jones ): In [changeset:"1860dae3a7e377f085f3a4134f532a7f577fccbe/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1860dae3a7e377f085f3a4134f532a7f577fccbe" Suggest TemplateHaskell after encountering a parse error on '$' (#7396) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 5 08:34:30 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Dec 2013 08:34:30 -0000 Subject: [GHC] #8577: Polymorphism and typed TH In-Reply-To: <047.42718c612858c204c7b6a7535f3af16b@haskell.org> References: <047.42718c612858c204c7b6a7535f3af16b@haskell.org> Message-ID: <062.7a7d6799290264785c59038e2adf99eb@haskell.org> #8577: Polymorphism and typed TH -------------------------------------+------------------------------------ Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"3e66489ebcef0f4cd86968c6781a1d4ad1981f94/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="3e66489ebcef0f4cd86968c6781a1d4ad1981f94" Test Trac #8577 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 5 08:58:03 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Dec 2013 08:58:03 -0000 Subject: [GHC] #8577: Polymorphism and typed TH In-Reply-To: <047.42718c612858c204c7b6a7535f3af16b@haskell.org> References: <047.42718c612858c204c7b6a7535f3af16b@haskell.org> Message-ID: <062.1407470119317e00c3dcf156cfb20216@haskell.org> #8577: Polymorphism and typed TH -------------------------------------+------------------------------------ Reporter: monoidal | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Good catch! A terrible bug. Thanks. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 5 09:00:35 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Dec 2013 09:00:35 -0000 Subject: [GHC] #8589: Bad choice of loop breaker with INLINABLE/INLINE In-Reply-To: <052.029d6667ad632c5148f8f98b3c4c0bd3@haskell.org> References: <052.029d6667ad632c5148f8f98b3c4c0bd3@haskell.org> Message-ID: <067.a2b79581df82dfabc33b8b9e0d46bff6@haskell.org> #8589: Bad choice of loop breaker with INLINABLE/INLINE --------------------------------------------+------------------------------ Reporter: NickSmallbone | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): Currently the only (useful) behaviour of INLINEABLE for recursive functions is to allow type-class-overloaded functions to be specialised. That's why I think a name-change might be in order. We never specialise non-overloaded functions; doing so would simply generate two copies of the same machine code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 5 12:51:53 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Dec 2013 12:51:53 -0000 Subject: [GHC] #7307: Share top-level code for strings In-Reply-To: <046.a08650f8cdd36d5e1fecd64b2886fdde@haskell.org> References: <046.a08650f8cdd36d5e1fecd64b2886fdde@haskell.org> Message-ID: <061.fe9c9bbd0a08dc35ee4129b3f1378cfe@haskell.org> #7307: Share top-level code for strings -------------------------------------+------------------------------------ Reporter: simonpj | Owner: parcs Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by parcs): Hah, that's a lot of bugs for such a small patch. Your first point seems to contradict the documentation at https://ghc.haskell.org/trac/ghc/browser/ghc/includes/rts/storage/Closures.h#L30, which says that the usage of `StgThunkHeader` doesn't apply to `THUNK_STATIC`s. Could you clarify this? It seems to me that I could have just given the `TopUnpack` infotable the `THUNK_STATIC` type instead of creating a new closure type. Would you be inclined to agree? Thanks for reviewing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 5 13:15:47 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Dec 2013 13:15:47 -0000 Subject: [GHC] #5013: sporadic failures during compilation under solaris In-Reply-To: <045.60b676bf3753dc6058e807ea654417dd@haskell.org> References: <045.60b676bf3753dc6058e807ea654417dd@haskell.org> Message-ID: <060.c9ab18604a1e70a6cda7ef3c246a53cf@haskell.org> #5013: sporadic failures during compilation under solaris ----------------------------------+--------------------------- Reporter: maeder | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 7.0.4 Resolution: worksforme | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+--------------------------- Comment (by maeder): I made further 1500 compilation tests and found 5 failures for the unpatched version ghc-7.6.2 and none for my patched ghc-7.6.3 (In my previous comment it was ghc-7.6 instead of ghc-6.8.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 5 13:30:44 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Dec 2013 13:30:44 -0000 Subject: [GHC] #8590: Reduce code size of CAFs In-Reply-To: <044.abfe0e6f5cd5b3fe2a2632f41576ec73@haskell.org> References: <044.abfe0e6f5cd5b3fe2a2632f41576ec73@haskell.org> Message-ID: <059.d66f14d1481a1377826e861df9007509@haskell.org> #8590: Reduce code size of CAFs -------------------------------------+------------------------------------ Reporter: parcs | Owner: parcs Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by parcs): This patch removed the last user of the constructor `LambdaFormInfo.LFBlackHole`. A comment in the code alludes to removing it, and now it is possible to do so. See https://ghc.haskell.org/trac/ghc/browser/ghc/compiler/codeGen/StgCmmClosure.hs#L183 So, should it be removed now? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 5 15:20:49 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Dec 2013 15:20:49 -0000 Subject: [GHC] #8590: Reduce code size of CAFs In-Reply-To: <044.abfe0e6f5cd5b3fe2a2632f41576ec73@haskell.org> References: <044.abfe0e6f5cd5b3fe2a2632f41576ec73@haskell.org> Message-ID: <059.e93e7dbb0b06fbf98ad78a1f4317b2d4@haskell.org> #8590: Reduce code size of CAFs -------------------------------------+------------------------------------ Reporter: parcs | Owner: parcs Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): Yes, go ahead and remove it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 5 19:14:56 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Dec 2013 19:14:56 -0000 Subject: [GHC] #8596: windows link failure due to excessively long gcc commad line "Unable to start C:\Program Files\Haskell + Platform\2013.2.0.0\mingw\bin/realgcc.exe (error code: 87)" Message-ID: <047.4af16120e3d32bd0dd2986d2dd5dd2de@haskell.org> #8596: windows link failure due to excessively long gcc commad line "Unable to start C:\Program Files\Haskell + Platform\2013.2.0.0\mingw\bin/realgcc.exe (error code: 87)" ----------------------------+--------------------------------- Reporter: joeyhess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+--------------------------------- I have a program (git-annex) which builds successfully on windows, but when I enable any of three optional features which pull in some additional libraries, it fails to link. I will attach the output of cabal build --ghc-options=-v for a failing and a successful build. I hypothesize this is due to a command line length limit. The final failing gcc link command is 43814 characters, vs 30765 in the configuration that succeeds. Right around the 32k boundry. Not sure what I can do to work around this, short of splitting up my program into standalone libraries which will link without referencing every individual module? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 5 20:31:00 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Dec 2013 20:31:00 -0000 Subject: [GHC] #8596: windows link failure due to excessively long gcc commad line "Unable to start C:\Program Files\Haskell + Platform\2013.2.0.0\mingw\bin/realgcc.exe (error code: 87)" In-Reply-To: <047.4af16120e3d32bd0dd2986d2dd5dd2de@haskell.org> References: <047.4af16120e3d32bd0dd2986d2dd5dd2de@haskell.org> Message-ID: <062.ff4973ef6b2e6b773b692d0e6b21766c@haskell.org> #8596: windows link failure due to excessively long gcc commad line "Unable to start C:\Program Files\Haskell + Platform\2013.2.0.0\mingw\bin/realgcc.exe (error code: 87)" ---------------------------------+--------------------------- Reporter: joeyhess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+--------------------------- Comment (by refold): `gcc` has a feature called [http://gcc.gnu.org/wiki/Response_Files response files] that allows to work around this problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 5 20:48:03 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Dec 2013 20:48:03 -0000 Subject: [GHC] #8596: windows link failure due to excessively long gcc commad line "Unable to start C:\Program Files\Haskell + Platform\2013.2.0.0\mingw\bin/realgcc.exe (error code: 87)" In-Reply-To: <047.4af16120e3d32bd0dd2986d2dd5dd2de@haskell.org> References: <047.4af16120e3d32bd0dd2986d2dd5dd2de@haskell.org> Message-ID: <062.a4f7e8b96450e039d7e842590541baba@haskell.org> #8596: windows link failure due to excessively long gcc commad line "Unable to start C:\Program Files\Haskell + Platform\2013.2.0.0\mingw\bin/realgcc.exe (error code: 87)" ---------------------------------+--------------------------- Reporter: joeyhess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+--------------------------- Comment (by joeyhess): Thanks, that's really helpful. Is there any interface in ghc to use response files? If not, please consider this a feature request. ;) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 5 21:32:35 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Dec 2013 21:32:35 -0000 Subject: [GHC] #8596: windows link failure due to excessively long gcc commad line "Unable to start C:\Program Files\Haskell + Platform\2013.2.0.0\mingw\bin/realgcc.exe (error code: 87)" In-Reply-To: <047.4af16120e3d32bd0dd2986d2dd5dd2de@haskell.org> References: <047.4af16120e3d32bd0dd2986d2dd5dd2de@haskell.org> Message-ID: <062.cdb12e6e8b7ec3951c789031d50cf8df@haskell.org> #8596: windows link failure due to excessively long gcc commad line "Unable to start C:\Program Files\Haskell + Platform\2013.2.0.0\mingw\bin/realgcc.exe (error code: 87)" ---------------------------------+--------------------------- Reporter: joeyhess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+--------------------------- Comment (by joeyhess): I have verified that I can use response files to link my program. Currently generating the file from ghc -v output: cabal build --ghc-options='-v -keep-tmp-files' > build.log 2>&1 grep '"dist\\build\\git-annex\\git-annex.exe"' build.log | sed -e 's/^"[^"]*" //' -e 's/\\/\//g' > gcc.opt gcc @gcc.opt Refold probably saved me weeks of refactoring into libraries. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 5 21:34:34 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Dec 2013 21:34:34 -0000 Subject: [GHC] #8497: clang/wrapper cannot build GHC head with integer-gmp on Mavericks In-Reply-To: <052.a945a4fdb4d0e9bf62bd4d9ed8afe8eb@haskell.org> References: <052.a945a4fdb4d0e9bf62bd4d9ed8afe8eb@haskell.org> Message-ID: <067.91d60a8cc0fdfd9521c211db061f8f54@haskell.org> #8497: clang/wrapper cannot build GHC head with integer-gmp on Mavericks ----------------------------------------+---------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: clang Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by kazu-yamamoto): May I ask to merge this patch before GHC 7.8.1? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 5 21:55:09 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Dec 2013 21:55:09 -0000 Subject: [GHC] #7307: Share top-level code for strings In-Reply-To: <046.a08650f8cdd36d5e1fecd64b2886fdde@haskell.org> References: <046.a08650f8cdd36d5e1fecd64b2886fdde@haskell.org> Message-ID: <061.abc6ef08e6fcd8626d70f31f1f011e3f@haskell.org> #7307: Share top-level code for strings -------------------------------------+------------------------------------ Reporter: simonpj | Owner: parcs Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ezyang): You may be right; static thunks might be blackholed anyway so the update can be done atomically. But I'd have to check: note the comment also states that static thunks have no payload; this is not true for TopUnpack. I am not sure if adjusting THUNK_STATIC to now take a payload will cause any problems. Probably it's best to check all cases in the RTS that handle this closure type and see if they have any assumptions about payload sie. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 6 04:40:36 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Dec 2013 04:40:36 -0000 Subject: [GHC] #7986: make newBroadcastTChanIO match newBroadcastTChan In-Reply-To: <051.4ff8d5ff3d135999a1d792ab5a0209f0@haskell.org> References: <051.4ff8d5ff3d135999a1d792ab5a0209f0@haskell.org> Message-ID: <066.9b96fc50f9a69e721c806d50cb94b0db@haskell.org> #7986: make newBroadcastTChanIO match newBroadcastTChan -------------------------------+------------------------------------------- Reporter: | Owner: WrenThornton | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by khyperia): Is this ticket still valid? If my guess is correct, these functions eventually transformed into `newChan` in libraries/base/Control/Concurrent/Chan.hs, but I'm not sure. Not sure what to do about this ticket, though - it's still in "new" status. (I found it while digging for tickets to do) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 6 05:03:46 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Dec 2013 05:03:46 -0000 Subject: [GHC] #7986: make newBroadcastTChanIO match newBroadcastTChan In-Reply-To: <051.4ff8d5ff3d135999a1d792ab5a0209f0@haskell.org> References: <051.4ff8d5ff3d135999a1d792ab5a0209f0@haskell.org> Message-ID: <066.e319a58caa59178da35de66b7b612481@haskell.org> #7986: make newBroadcastTChanIO match newBroadcastTChan -------------------------------------+------------------------------------- Reporter: WrenThornton | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries | Version: 7.6.3 (other) | Keywords: stm Resolution: fixed | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: None/Unknown | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by rwbarton): * keywords: => stm * resolution: => fixed * status: new => closed * component: Compiler => libraries (other) Comment: Yep, this was committed in https://github.com/ghc/packages- stm/commit/1187332f18de8bdd8ede1d940fe035fe0acac424. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 6 05:16:30 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Dec 2013 05:16:30 -0000 Subject: [GHC] #8590: Reduce code size of CAFs In-Reply-To: <044.abfe0e6f5cd5b3fe2a2632f41576ec73@haskell.org> References: <044.abfe0e6f5cd5b3fe2a2632f41576ec73@haskell.org> Message-ID: <059.d8b4b9f311519101d72801bddb9f88be@haskell.org> #8590: Reduce code size of CAFs -------------------------------------+------------------------------------ Reporter: parcs | Owner: parcs Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by parcs): I am attempting to further reduce the code size of CAFs by moving the CAF- updating code out from each CAF and into a shared "CAF" info-table. For example, consider the module {{{ #!haskell module CAF where a = "test" }}} Currently, the Cmm outputted for this module looks like {{{ #!c [section "data" { CAF.a_closure: const CAF.a_info; const 0; const 0; const 0; }, section "readonly" { cCM_str: I8[] [116,101,115,116] }, CAF.a_entry() // [R1] { info_tbl: [(cCN, label: CAF.a_info rep:HeapRep static { Thunk })] stack_info: arg_space: 8 updfr_space: Just 8 } {offset cCN: if ((Sp + -16) < SpLim) goto cCO; else goto cCP; cCO: R1 = R1; call (stg_gc_enter_1)(R1) args: 8, res: 0, upd: 8; cCP: (_cCJ::I64) = call "ccall" arg hints: [PtrHint, PtrHint] result hints: [PtrHint] newCAF(BaseReg, R1); if (_cCJ::I64 == 0) goto cCL; else goto cCK; cCL: call (I64[R1])() args: 8, res: 0, upd: 8; cCK: I64[Sp - 16] = stg_bh_upd_frame_info; I64[Sp - 8] = _cCJ::I64; R2 = cCM_str; Sp = Sp - 16; call GHC.CString.unpackCString#_info(R2) args: 24, res: 0, upd: 24; } }] }}} Each CAF is augmented with code that handles the updating of the CAF itself. This is the `newCAF()` stuff shown above. It should be possible to refactor the CAF-updating out of the entry code of a CAF and into a special "CAF" info table. For example, the above code could look like {{{ #!c [section "data" { CAF.a_closure: const stg_CAF_info; // XXX new info table const 0; const 0; const CAF.a_info; // pointer to the "real" info table // this field corresponds to the saved_info field of an StgIndstatic }, section "readonly" { cCK_str: I8[] [116,101,115,116] }, CAF.a_entry() // [R1] { info_tbl: [(cCL, label: CAF.a_info rep:HeapRep static { Thunk })] stack_info: arg_space: 8 updfr_space: Just 8 } {offset cCL: // no CAF boilerplate here! R2 = cCK_str; call GHC.CString.unpackCString#_info(R2) args: 8, res: 0, upd: 8; } }] }}} where `stg_CAF_info` is the info table that encapsulates the CAF-specific code: {{{ #!c INFO_TABLE(stg_CAF, 0, 0, THUNK_STATIC, "CAF", "CAF") (P_ node) { P_ bh; W_ info; STK_CHK_GEN(); info = StgIndStatic_saved_info(node); ("ptr" bh) = ccall newCAF(BaseReg "ptr", node "ptr"); if (bh == 0) { jump %GET_ENTRY(node) (); } else { push (stg_bh_upd_frame_info, bh) { jump (%ENTRY_CODE(info)) (); } } } }}} Firstly, I wonder whether this approach is feasible. Is there a reason why CAF updates are not implemented this way in the first place? I have a tentative patch that implements this approach, and it does produce correct results given contrived input -- but when I try bootstrap GHC with the patch, the dll-split program (which is built against ghc- stage1) segfaults. So there is strong reason to believe that there is something flawed about the idea and/or the implementation. My STG-fu is still weak, and I am failing to figure out the source of the problem. dll-split does not have any CAFs Does anybody have any insights on Does anyone have any insights on this approach of updating CAFs and on what may be causing the segfault? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 6 06:32:07 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Dec 2013 06:32:07 -0000 Subject: [GHC] #8429: GHC.Base.{breakpoint, breakpointCond} do nothing In-Reply-To: <045.4c9eb90270eb503495dbeb412abc60e7@haskell.org> References: <045.4c9eb90270eb503495dbeb412abc60e7@haskell.org> Message-ID: <060.10d5c3ced55acb64ff4a32f712206ab8@haskell.org> #8429: GHC.Base.{breakpoint, breakpointCond} do nothing -------------------------------------+------------------------------------ Reporter: refold | Owner: iand675 Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 1377 -------------------------------------+------------------------------------ Changes (by iand675): * owner: => iand675 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 6 10:02:03 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Dec 2013 10:02:03 -0000 Subject: [GHC] #8590: Reduce code size of CAFs In-Reply-To: <044.abfe0e6f5cd5b3fe2a2632f41576ec73@haskell.org> References: <044.abfe0e6f5cd5b3fe2a2632f41576ec73@haskell.org> Message-ID: <059.c8c31a3635c4cf474509eadaacc943be@haskell.org> #8590: Reduce code size of CAFs -------------------------------------+------------------------------------ Reporter: parcs | Owner: parcs Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): I think it's a good idea, and it's great that you're finding ways to squeeze the code size. Keep at it! :) > jump (%ENTRY_CODE(info)) () I think you'll want that to be {{{ jump (%ENTRY_CODE(info)) (node) }}} One other thing you'll need to look at is reverting CAFs, which will need to put the `stg_CAF_info` back, rather than the saved info pointer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 6 10:19:46 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Dec 2013 10:19:46 -0000 Subject: [GHC] #8597: Git Hook script to prevent large binary blobs being checked in Message-ID: <042.1f60f889f27cefcd4aaab3c10659d3bb@haskell.org> #8597: Git Hook script to prevent large binary blobs being checked in ------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- It has already occurred in the past in `testsuite.git` repo, that executables were checked in by accident, and caused the Git history to get bloated. In order to avoid such accidents in the future a Git hook script in the style of [http://stackoverflow.com/questions/20226132/is-there-a-git-hook- which-can-prevent-binary-check-ins this] might be useful, but taking also into account the size, and/or possibly with a magic safeword to be put in the commit message, to override the check for a single commit, if the author really knows what (s)he's doing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 6 10:54:25 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Dec 2013 10:54:25 -0000 Subject: [GHC] #8598: IO hack in demand analyzer gets in the way of CPR Message-ID: <046.257cc2180dce5fcae9e4dfcb90ad22aa@haskell.org> #8598: IO hack in demand analyzer gets in the way of CPR ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- After a lot of staring at code and comparing unexpected nofib results I found the following: The IO hack in the demand analyzer (see `dmdAnalAlt` in `StrAnal.lhs` and #1592 for a good discussion) prevents CPR in any function that uses a C call. This is a small example, reduced from the `scaleFloat` method for doubles: {{{ module Float(fun) where import GHC.Float (Double(..)) import GHC.Integer (decodeDoubleInteger, encodeDoubleInteger) fun :: Double -> Double fun x | isFix = x | otherwise = case x of (D# x#) -> case decodeDoubleInteger x# of (# i, j #) -> D# (encodeDoubleInteger i j) where isFix = isDoubleFinite x == 0 foreign import ccall unsafe "isDoubleFinite" isDoubleFinite :: Double -> Int }}} Here, `fun` does current not get the CPR property, and the work gets type `GHC.Prim.Double# -> GHC.Types.Double`. Why? Because in core, there will be a {{{ case {__pkg_ccall main isDoubleFinite GHC.Prim.Double# -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Prim.Int# #)}_dQD ds_dQA GHC.Prim.realWorld# of _ [Occ=Dead, Dmd=] { (# ds_dQC [Dmd=, OS=OneShot], ds_dQB [Dmd=] #) -> ... }}} where the case body has `DmdType m {dQz-> dQA->}`, but `dmdAnalAlt` detects that this is evaluating a possibly exiting function and throws aways the information using `alt_ty `lubDmdType` topDmdType`. Would it be ok to `lub` only the demand on the free variables, but keep the CPR information? In nofib (if I managed to compare the right results) this does nothing for almost all benchmarks, `-9.2%` of allocations for `mandel` and `+4.9%` for reverse-complement (but these numbers are not obtained very cleanly, and all is happening on top of the better-ho-cardinality branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 6 11:02:51 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Dec 2013 11:02:51 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.9a3358e5aa41c2381afb701b2dc39829@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: nomeata Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8598 -------------------------------------+------------------------------------- Changes (by nomeata): * related: => #8598 Comment: Also see ticket #8598 (CPR after IO action) which is not directly related to nested cpr, but will become more relevant when want to do nested CPR inside `IO`, such as in this example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 6 11:41:07 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Dec 2013 11:41:07 -0000 Subject: [GHC] #8598: IO hack in demand analyzer gets in the way of CPR In-Reply-To: <046.257cc2180dce5fcae9e4dfcb90ad22aa@haskell.org> References: <046.257cc2180dce5fcae9e4dfcb90ad22aa@haskell.org> Message-ID: <061.8c8cbb2ce2560943f794f612997e2008@haskell.org> #8598: IO hack in demand analyzer gets in the way of CPR -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): A shower later I believe I have a quite decent solution: Currently, the CPR lattice has these elements: {{{ NoCPR / \ ReProd RetSum \ / BotCPR }}} where `BotCPR` not only tells us that there is not going to be a result, but also that the function is ''diverging'' (and hence puts a hyperstrict demand on free variables). For the hypothesised ?clean exit of the IO function? we need something in between: {{{ NoCPR / \ ReProd RetSum \ / ExitCPR | BotCPR }}} `ExitCPR` behaves like `BotCPR` when with regard to `lub`ing it with another result (i.e. whatever the other things knows about the result stays there), but has a `` demand on free variables. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 6 13:58:40 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Dec 2013 13:58:40 -0000 Subject: [GHC] #8578: Improvements to SpinLock implementation In-Reply-To: <044.7d4d696b896537d8c685483f715ea999@haskell.org> References: <044.7d4d696b896537d8c685483f715ea999@haskell.org> Message-ID: <059.898884555a691a00376cf3ceed712640@haskell.org> #8578: Improvements to SpinLock implementation -------------------------------------+------------------------------------ Reporter: parcs | Owner: parcs Type: task | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): Here are my results with `-N4` on an Intel Core i7-3770 (4 cores, 8 threads). {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- blackscholes +0.0% +0.0% -1.7% -2.4% -0.3% coins +0.0% -0.0% +0.4% +1.0% -8.6% gray +0.0% +0.0% +15.1% +14.3% +0.0% mandel +0.0% +0.0% +3.3% +3.3% -0.8% matmult +0.0% +8.1% -2.4% -2.6% +0.0% minimax +0.0% +0.0% -1.3% -1.1% +0.0% nbody +0.0% -6.0% -1.9% 0.06 +0.0% parfib +0.0% +0.1% +16.2% +16.2% +0.0% partree +0.0% -0.0% +1.0% +0.5% -3.0% prsa +0.0% -0.1% +1.1% +0.9% +0.0% queens +0.0% -0.5% -1.3% -0.5% +7.1% ray +0.0% -0.3% -0.4% -0.5% +0.0% sumeuler +0.0% +0.0% +1.0% +1.0% +0.0% transclos +0.0% +0.0% +1.2% +1.4% +0.0% -------------------------------------------------------------------------------- Min +0.0% -6.0% -2.4% -2.6% -8.6% Max +0.0% +8.1% +16.2% +16.2% +7.1% Geometric Mean +0.0% +0.1% +2.0% +2.3% -0.4% }}} Not good! Two programs (gray and parfib) are significantly worse. The effect is real, here is the timing info for parfib before and after: {{{ 5.70user 0.00system 0:01.43elapsed 397%CPU (0avgtext+0avgdata 20816maxresident)k 6.52user 0.00system 0:01.64elapsed 397%CPU (0avgtext+0avgdata 21568maxresident)k }}} I wonder whether not using a locked instruction in the spinlock might cause the loop to spin for longer, because it takes longer for the memory write to reach the core that is waiting for it? Someone could probably dig into this further with perf. But the lesson here, as usual, is to always benchmark and don't just assume that because it looks good it will work in practice! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 6 14:40:09 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Dec 2013 14:40:09 -0000 Subject: [GHC] #8598: IO hack in demand analyzer gets in the way of CPR In-Reply-To: <046.257cc2180dce5fcae9e4dfcb90ad22aa@haskell.org> References: <046.257cc2180dce5fcae9e4dfcb90ad22aa@haskell.org> Message-ID: <061.9f54d0e3f48ee6d28cccb66b96021918@haskell.org> #8598: IO hack in demand analyzer gets in the way of CPR -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Mail from SPJ: Well spotted. I'm on a train, hence email response. Maybe you can paste this into the ticket? There are two different issues here. '''First''', `isDoubleFinite` is declared as non-side-effecting: {{{ foreign import ccall unsafe "isDoubleFinite" isDoubleFinite :: Double -> Int }}} But (as you can see from the code you give) we currently desugar it into something that looks (to Core) as though it might have a side effect, or raise a (synchronous) exception. That is stupid. How might we fix that? I can think of two ways. * Generate a `FCallId` whose type is `Double -> Int` rather than (as now) `Double -> IO Int`. There would be a few knock-on consequences to make sure they were correctly code-generated. I like this path best, because it reflects the truth. * Currently {{{ IO a = State# RealWorld# -> (# State# RealWorld#, a #) }}} For these non-side-effecting things we could instead generate a `FCallId` with a type involving `SafeIO` instead of `IO`: {{{ SafeIO a = State# SafeWorld# -> (# State# SafeWorld#, a #) }}} The different "world token" would express the idea that the function can't throw an exception. I don't like this as much, but it might in any case be useful for things that ''do'' have side effects but ''don't'' throw exceptions. My preference is for the first. '''Second''', as you point out, consider {{{ f x = do { when (x>3) exit ; return (True, False) } }}} Function `f` might throw an exception or exit rather than returning, but ''if it does return'' it will certainly have the CPR property. So yes, CPR-ness is quite safe. It's not quite so obvious for divergence: {{{ g x = do { when (x>3) exit ; g x } h 0 y = y h x y = g x }}} Is `h` strict in `y`? You might say (reasonably) that we can ignore the possible IO exception/exit in `g` when figuring out that `g` is sure to diverge. If so, we'd say that `h` is strict in `y`. But if `(x>3)` then really `y` is not evaluated... and spotting that is exactly what the IO hack in the demand analyser is spotting. So I think it is ''not'' safe to propagate divergence information. In short, CPR info yes, guaranteed-divergence no. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 6 14:41:14 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Dec 2013 14:41:14 -0000 Subject: [GHC] #8598: IO hack in demand analyzer gets in the way of CPR In-Reply-To: <046.257cc2180dce5fcae9e4dfcb90ad22aa@haskell.org> References: <046.257cc2180dce5fcae9e4dfcb90ad22aa@haskell.org> Message-ID: <061.2cd2e7dfe7fd994dbe34104cb802ce0f@haskell.org> #8598: IO hack in demand analyzer gets in the way of CPR -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): > In short, CPR info yes, guaranteed-divergence no. Which is precisely what we obtain from adding `ExitCPR` to the lattice, as {{{ExitCPR `lub` BotCPR = ExitCPR}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 6 16:17:36 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Dec 2013 16:17:36 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.3a21e208cd8c64f81fefdf6b43a64897@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: nomeata Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8598 -------------------------------------+------------------------------------- Comment (by nomeata): Finally I got the code in a shape good enough for controlled experiments. I started with a merge of branch `better-ho-cardinality` and master (at [4025d66/ghc]). This is my baseline. The next measurement is with the nested CPR analysis, but without changing the worker-wrapper code, i.e. the CPR information is only used as far as before. Here is the result (skipping lines with `+0.0%`): {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- cacheprof +0.0% +0.6% +0.3% +0.6% -3.4% -------------------------------------------------------------------------------- Min +0.0% -0.0% -8.9% -8.7% -3.4% Max +0.1% +0.6% +9.1% +9.1% +3.0% Geometric Mean +0.0% +0.0% -0.4% -0.4% -0.0% }}} I did not look at `cacheprof`, but I am confident that I did not break anything serious by introducing nested CPR to the analysis. Next measurement is is with the worker/wrapper code handling nested CPR, but using `-fnested-cpr-off` to make sure that all CPR information is actually what we had before. I used this to ensure that my `mkWWcpr`-implementation did not regress over the old one (it turned out that I did mess up in various ways, so this is important): {{{ -------------------------------------------------------------------------------- cacheprof +0.0% -0.6% -0.3% -0.6% +1.8% -------------------------------------------------------------------------------- Min +0.0% -0.6% -1.4% -1.7% +0.0% Max +0.0% +0.0% +2.3% +2.4% +1.8% Geometric Mean -0.0% -0.0% +0.1% +0.1% +0.0% }}} And now the exciting part: The same code, but now without `-fnested-cpr- off`: {{{ -------------------------------------------------------------------------------- anna +0.5% +0.1% 0.18 0.19 +0.0% boyer2 +0.5% +0.4% 0.01 0.01 +0.0% bspt +1.1% +0.2% 0.01 0.01 +0.0% cacheprof +0.5% -0.7% +0.6% +1.2% -2.6% calendar +0.5% +0.1% 0.00 0.00 +0.0% comp_lab_zift +0.5% +0.1% +0.0% +0.0% +0.0% infer +0.4% -1.2% 0.09 0.09 +0.0% para +0.4% +0.2% -1.5% -1.5% +0.0% prolog +0.5% +0.2% 0.00 0.00 +0.0% reptile +0.7% +0.3% 0.02 0.02 +0.0% -------------------------------------------------------------------------------- Min +0.4% -1.2% -8.0% -8.0% -4.4% Max +1.1% +0.4% +6.9% +6.9% +4.2% Geometric Mean +0.5% -0.0% +0.0% -0.0% -0.1% }}} so most of the 101 benchmarks are not affected by nested CPR (in its current, prelimary) form at all (besides a quite reliable increase of binary sizes by `+0.5%` ? does Size include `.hi`-files?). When it changes the Allocs number the effect is small and indecisive. It may be that fixing #8598 would improve matters (or at least allow nested CPR to occur more often, whether for the better or for the worse, I don?t know.) I might look at that next, but probably off master, as it is an independent feature. Of course it is also quite likely that the nested CPR analysis needs more tuning by looking at code where we want it to fire. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 6 17:00:25 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Dec 2013 17:00:25 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.c3f3ea3f68a49ea2b2d17ca30a2c0329@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: nomeata Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8598 -------------------------------------+------------------------------------- Comment (by nomeata): The change of allocations in `cacheprof` is weird: the output of `-ddump- simpl` is identical (ignoring unique numbers and strictness annotations). So there is a change hidden in the libraries somewhere... hopefully nothing to worry about. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 6 20:41:23 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Dec 2013 20:41:23 -0000 Subject: [GHC] #8550: GHC builds recursive coerctions when using recursive type families In-Reply-To: <046.8d217bb04ee5a5aa0080a8650276d1a6@haskell.org> References: <046.8d217bb04ee5a5aa0080a8650276d1a6@haskell.org> Message-ID: <061.93c8e25bbc601007b352188df90fed81@haskell.org> #8550: GHC builds recursive coerctions when using recursive type families --------------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by monoidal): Could you check whether it works now? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 6 22:19:33 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Dec 2013 22:19:33 -0000 Subject: [GHC] #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request In-Reply-To: <051.57f61623dcae713596d5a8bb0b9f83bb@haskell.org> References: <051.57f61623dcae713596d5a8bb0b9f83bb@haskell.org> Message-ID: <066.273de7e935e76698c6b3e3850926ddcd@haskell.org> #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request -------------------------------------+------------------------------------ Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by carter): * cc: carter.schonwald@? (added) * failure: => None/Unknown * version: 6.6.1 => 7.7 Comment: bumping the version, this still holds in head -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 6 22:40:33 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Dec 2013 22:40:33 -0000 Subject: [GHC] #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request In-Reply-To: <051.57f61623dcae713596d5a8bb0b9f83bb@haskell.org> References: <051.57f61623dcae713596d5a8bb0b9f83bb@haskell.org> Message-ID: <066.10329f68d89d610ec7785ee2e46106eb@haskell.org> #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request -------------------------------------+------------------------------------ Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): Would a first step towards something in this direction be a Strict Newtype? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 6 23:10:28 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Dec 2013 23:10:28 -0000 Subject: [GHC] #8598: IO hack in demand analyzer gets in the way of CPR In-Reply-To: <046.257cc2180dce5fcae9e4dfcb90ad22aa@haskell.org> References: <046.257cc2180dce5fcae9e4dfcb90ad22aa@haskell.org> Message-ID: <061.bf670906ceb94c23f3839338e89ad1e2@haskell.org> #8598: IO hack in demand analyzer gets in the way of CPR -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Nofib believes that this is a good change (runtime not reliable, as I ran other stuff in parallel): {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- fft2 -0.0% -0.1% 0.10 0.10 +0.0% mandel -0.0% -9.2% 0.10 0.10 +0.0% nucleic2 -0.0% -0.3% 0.10 0.10 +0.0% -------------------------------------------------------------------------------- Min -0.1% -9.2% -3.4% -4.1% +0.0% Max -0.0% +0.0% +18.5% +19.3% +0.0% Geometric Mean -0.0% -0.1% +1.7% +1.6% -0.0% }}} I?ll push it to branch `wip/T8598` for review. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 6 23:22:03 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Dec 2013 23:22:03 -0000 Subject: [GHC] #8550: GHC builds recursive coerctions when using recursive type families In-Reply-To: <046.8d217bb04ee5a5aa0080a8650276d1a6@haskell.org> References: <046.8d217bb04ee5a5aa0080a8650276d1a6@haskell.org> Message-ID: <061.00ae41ab3d778b565d6be0b6a618d443@haskell.org> #8550: GHC builds recursive coerctions when using recursive type families --------------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by nomeata): Yes, same thing. What would make you think it changed since two weeks ago? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 6 23:45:35 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Dec 2013 23:45:35 -0000 Subject: [GHC] #8550: GHC builds recursive coerctions when using recursive type families In-Reply-To: <046.8d217bb04ee5a5aa0080a8650276d1a6@haskell.org> References: <046.8d217bb04ee5a5aa0080a8650276d1a6@haskell.org> Message-ID: <061.a2015f9b5e08a5dab6347a33a0315488@haskell.org> #8550: GHC builds recursive coerctions when using recursive type families --------------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by monoidal): Sorry, I couldn't reproduce; now I see the panic needs compiling with DEBUG. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 6 23:47:17 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Dec 2013 23:47:17 -0000 Subject: [GHC] #8550: GHC builds recursive coerctions when using recursive type families In-Reply-To: <046.8d217bb04ee5a5aa0080a8650276d1a6@haskell.org> References: <046.8d217bb04ee5a5aa0080a8650276d1a6@haskell.org> Message-ID: <061.38ec4a4f1f121ff457da9fcc62ee6382@haskell.org> #8550: GHC builds recursive coerctions when using recursive type families --------------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by nomeata): Ah, ok. Did not try that. What happens when you actually run the code? I assume it will just loop... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 6 23:49:38 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Dec 2013 23:49:38 -0000 Subject: [GHC] #8550: GHC builds recursive coerctions when using recursive type families In-Reply-To: <046.8d217bb04ee5a5aa0080a8650276d1a6@haskell.org> References: <046.8d217bb04ee5a5aa0080a8650276d1a6@haskell.org> Message-ID: <061.e2493c28ee34a4f39011e44112be2dca@haskell.org> #8550: GHC builds recursive coerctions when using recursive type families --------------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by monoidal): Right. `main = seq A (return ())` loops. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 7 10:15:32 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Dec 2013 10:15:32 -0000 Subject: [GHC] #8598: IO hack in demand analyzer gets in the way of CPR In-Reply-To: <046.257cc2180dce5fcae9e4dfcb90ad22aa@haskell.org> References: <046.257cc2180dce5fcae9e4dfcb90ad22aa@haskell.org> Message-ID: <061.25027b937b030a203e63ff11f581c871@haskell.org> #8598: IO hack in demand analyzer gets in the way of CPR -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Also note that the current IO hack is very erratic with regard to IO inside `unsafePerformIO` (including non-IO FFI calls): It only zaps strictness demands if it actually sees the `IO` type. If, in the example above, `isDoubleFinite` were not inlined, but a separate function of type `Double -> IO Bool`, it would behave different. Very unsatisfying. This proposal should eliminate the need for special-casing in `StrAnal` completely, and make the analysis more precise. We could elaborate the `DmdResult` lattice some more (and I include the `Converges` from the nested-cpr-branch here, to show how that goes together). Basically we want the `DmdResult` to keep track of: * whether function may or will diverge. * whether the function may or will exit cleanly (this is new) * if it returns, what is the result. So a first approximation of that would be {{{ #!haskell data CPR = NoCRP | RetCon Int [DmdResult] data TriState = Yes | No | Maybe -- Maybe is top data DmdResult = DmdResult { diverges :: TriState, exits :: TriState, cpr :: CPR } -- Product lattice }}} which is easy to understand and handle, but it has some invalid states, i.e. if it definitely exits or diverges, we do not really want a `CPR` field, and also not both `diverges` and `exists` should be `True` at the same time. A format that captures it more precisely would be {{{ #!haskell data DmdResult = Diverges | Exits | DmdResult { mayExit :: True, mayDiverge :: True, cpr :: CPR} }}} which neatly expresses definite convergence with `DmdResult False False cpr`. I like that. So the idea is now that primitive operations have their `DmdResult` annotation manually (and I guess most of them do not exit). FFI calls either get a conservative default of `DmdResult True True NoCPR` for things in the `IO` monad and `DmdResult False True NoCPR` for the others. Then in the demand analyser no special handling of IO is required any more. Instead, in `bothDmdType`, one has to handle the `mayExit` flag of the right argument and possibly zap strictness, just like we do already for diverging things. And even `IO`-infested code will, as long as it does not call anything with `mayExit = True` (e.g. numerical calculation, working with arrays and `IORef`s), will get good strictness demands inferred. How does that sound? Or is it overkill adding this to the demand types, given that (hopefully) almost everything will have `mayExit = False`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 7 12:13:35 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Dec 2013 12:13:35 -0000 Subject: [GHC] #8599: Deriving in associated data families Message-ID: <047.15721e4f15b895eba1da55bf5a43686a@haskell.org> #8599: Deriving in associated data families ------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This code {{{ class Class a where data DF a data family DF' a instance (Eq (DF' a)) => Class a where newtype DF a = DF (DF' a) deriving (Eq) }}} fails with {{{ No instance for (Eq (DF' a)) arising from the 'deriving' clause of a data type declaration Possible fix: add an instance declaration for (Eq (DF' a)) or use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Eq (DF a)) }}} The following way it compiles fine, however {{{ class Class a where data DF a data family DF' a instance Class a where newtype DF a = DF (DF' a) deriving instance (Eq (DF' a)) => Eq (DF a) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 7 12:20:41 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Dec 2013 12:20:41 -0000 Subject: [GHC] #8599: Deriving in associated data families ignores instance's constraints (was: Deriving in associated data families) In-Reply-To: <047.15721e4f15b895eba1da55bf5a43686a@haskell.org> References: <047.15721e4f15b895eba1da55bf5a43686a@haskell.org> Message-ID: <062.dd5e62688f88b4d6e9f41c1c2701ccd4@haskell.org> #8599: Deriving in associated data families ignores instance's constraints -------------------------------------+------------------------------------ Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 7 12:51:05 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Dec 2013 12:51:05 -0000 Subject: [GHC] #7091: DPH Matrix product memory usage In-Reply-To: <046.ddf658542df82545bec4bdc69ee7d0da@haskell.org> References: <046.ddf658542df82545bec4bdc69ee7d0da@haskell.org> Message-ID: <061.02c907358ee9b43e97ae35d57d0dda94@haskell.org> #7091: DPH Matrix product memory usage --------------------------------------------+--------------------------- Reporter: mblanco | Owner: benl Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Data Parallel Haskell | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Runtime performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------------+--------------------------- Comment (by George): More specifially, in section 5.5 the paper states: nested parallelism can increase the asymptotic space complexity in a way that this paper does not address [15, 19]. ... The flattened version is a hylomorphism that first computes O(n{{{^}}}2) distances before reducing them to determine the maximum. Whereas the sequential version would run in O(n) space, the flattened version needs O(n{{{^}}}2) space to hold the intermediate vector of distances. Given the preceding this issue seems to be a known consequence of the dph algorithm and as such the status of this should be "Not a bug" as it is not a GHC bug. However this is just my opinion and I don't feel I have the expertise to actually change the bug status -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 7 13:20:39 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Dec 2013 13:20:39 -0000 Subject: [GHC] #8600: ghc --help is outdated Message-ID: <048.bdb06add437102212b23e2d2cf0573f6@haskell.org> #8600: ghc --help is outdated ------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- {{{ To compile and link a complete Haskell program, run the compiler like so: ghc --make Main where the module Main is in a file named Main.hs (or Main.lhs) in the current directory. The other modules in the program will be located and compiled automatically, and the linked program will be placed in the file `a.out' (or `Main.exe' on Windows). }}} First, --make is no longer necessary. Second, ghc doesn't create a.out on Unix ? instead, the file is named the same as the main module (Main in that example). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 7 22:17:49 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Dec 2013 22:17:49 -0000 Subject: [GHC] #5289: Can't use ghci with a library linked against libstdc++ In-Reply-To: <042.ca5f68f0f4907cc12990f083dfa50f2f@haskell.org> References: <042.ca5f68f0f4907cc12990f083dfa50f2f@haskell.org> Message-ID: <057.d1f03113809ff33445a14e2869dfb165@haskell.org> #5289: Can't use ghci with a library linked against libstdc++ -------------------------------------+------------------------------------ Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: GHCi | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by blitzcode): * cc: tim@?, hvr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 8 02:43:37 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Dec 2013 02:43:37 -0000 Subject: [GHC] #8601: runghc from standard input and --ghc-args Message-ID: <045.11cb225cfe1bdf84af2a31b9e73fe50d@haskell.org> #8601: runghc from standard input and --ghc-args ------------------------------------+------------------------------------- Reporter: wuzzeb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I am trying to use runghc with a cabal sandbox, and it works when the haskell code is in a file like follows: {{{ runghc -- -package-db --ghc-arg=.cabal-sandbox/i386-linux- ghc-7.6.3-packages.conf.d somefile.hs }}} But if I try and load the script from standard input (actually I am trying to run a GHC script from a bash script using "runghc << EOF" but it is easier to see if you just run from the console) {{{ runghc -- -package-db --ghc-arg=.cabal-sandbox/i386-linux- ghc-7.6.3-packages.conf.d < somefile.hs }}} you get an error {{{ .cabal-sandbox/i386-linux-ghc-7.6.3-packages.conf.d/:1:57: Not in scope: `main' Perhaps you meant `min' (imported from Prelude) }}} Looking at the utils/runghc/runghc.hs source file, what happens is inside the doIt function. The first thing the doIt function does is call getGhcArgs which strips the --ghc-args. Then it checks the args and sees there is no file, so falls into the case where it reads standard input, creates a temp file, and then recalls doIt. Here is the problem, because the "--ghc-arg" string has already been stripped so the second call to doIt is where the error occurs. With that, I can actually get it to work with the following :) {{{ runghc -- -package-db --ghc-arg=--ghc-arg=.cabal-sandbox/i386-linux- ghc-7.6.3-packages.conf.d < somefile.hs }}} By passing --ghc-arg= twice, it is stripped once the first time doIt is called and once the second time and GHC gets the correct args :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 8 03:02:20 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Dec 2013 03:02:20 -0000 Subject: [GHC] #8602: Wrong argument order to Haskell pre-processor (-F, -pgmF, -optF) Message-ID: <050.0f96b843acaeec89e0eea7d9a48c58ce@haskell.org> #8602: Wrong argument order to Haskell pre-processor (-F, -pgmF, -optF) -----------------------------------+--------------------------------------- Reporter: SimonHengel | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- So far, and that is what is documented > Additional arguments to the pre-processor can be passed in using the {{{-optF}}} option. These are fed to cmd on the command line after the three standard input and output arguments. However, {{{GHC 7.7.20131026}}} passes additional arguments (specified with {{{-optF}}}) before the three standard arguments. Steps to reproduce: {{{ $ echo '{-# OPTIONS_GHC -F -pgmF ./foo.sh -optF bar #-}' > Foo.hs $ echo 'echo $*' > foo.sh $ chmod +x foo.sh $ ghci Foo.hs }}} Expected result: {{{Foo.hs Foo.hs /tmp/ghc16665_0/ghc16665_1.hspp bar}}} is printed to stdout Actual result: {{{bar Foo.hs Foo.hs /tmp/ghc16665_0/ghc16665_1.hspp}}} is printed to stdout -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 8 07:15:48 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Dec 2013 07:15:48 -0000 Subject: [GHC] #8490: OS X 10.9 gcc-4.8 unknown symbol `__objc_empty_table` In-Reply-To: <044.5f5ec774064a8f6ab1662b91fc1d1daa@haskell.org> References: <044.5f5ec774064a8f6ab1662b91fc1d1daa@haskell.org> Message-ID: <059.c26469ceec37e49d0552a21e5c7b904d@haskell.org> #8490: OS X 10.9 gcc-4.8 unknown symbol `__objc_empty_table` ---------------------------------------+---------------------------------- Reporter: jloos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by guest): I'm having a similar problem, also on Mac OS X 10.9. Went through pretty much the same process and reached the same lack of conclusions. I've also verified that `/usr/lib/libobjc.dylib` does indeed contain some symbol `__objc_empty_vtable` as shown via `nm -g`, but I cannot get ghc to link to it properly. Any ideas? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 8 12:37:11 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Dec 2013 12:37:11 -0000 Subject: [GHC] #8598: IO hack in demand analyzer gets in the way of CPR In-Reply-To: <046.257cc2180dce5fcae9e4dfcb90ad22aa@haskell.org> References: <046.257cc2180dce5fcae9e4dfcb90ad22aa@haskell.org> Message-ID: <061.d5dff133990f4ff383d7ebce4924a4a4@haskell.org> #8598: IO hack in demand analyzer gets in the way of CPR -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Replying to [comment:4 nomeata]: > I?ll push it to branch `wip/T8598` for review. The branch validates. Should I push this, independent of the extended approach suggested later? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 8 15:01:18 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Dec 2013 15:01:18 -0000 Subject: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 In-Reply-To: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> References: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> Message-ID: <063.861d18e3740d8496e08625e533f7cb59@haskell.org> #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------+---------------------------------- Changes (by ihameed): * cc: idhameed@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 9 00:02:19 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Dec 2013 00:02:19 -0000 Subject: [GHC] #7091: DPH Matrix product memory usage In-Reply-To: <046.ddf658542df82545bec4bdc69ee7d0da@haskell.org> References: <046.ddf658542df82545bec4bdc69ee7d0da@haskell.org> Message-ID: <061.5658b63c9868ccf10e57e35bd2df3190@haskell.org> #7091: DPH Matrix product memory usage --------------------------------------------+--------------------------- Reporter: mblanco | Owner: benl Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Data Parallel Haskell | Version: 7.4.1 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Runtime performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------------+--------------------------- Changes (by benl): * status: new => closed * resolution: => invalid Comment: I've set it to invalid to clean up the ticket data base. This is a research problem, not a bug in the compiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 9 03:24:21 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Dec 2013 03:24:21 -0000 Subject: [GHC] #5144: Pattern synonyms In-Reply-To: <046.358306463908294bbc35edfc129eeda7@haskell.org> References: <046.358306463908294bbc35edfc129eeda7@haskell.org> Message-ID: <061.f61fff074756596a4a6a0087ba775464@haskell.org> #5144: Pattern synonyms -------------------------------------------+------------------------------- Reporter: simonpj | Owner: cactus Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: 8581, 8582, 8583, 8584 | Blocked By: | Related Tickets: -------------------------------------------+------------------------------- Comment (by cactus): I've added test cases to the `pattern-synonym` branch of https://github.com/gergoerdi/ghc-testsuite.git -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 9 09:12:05 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Dec 2013 09:12:05 -0000 Subject: [GHC] #8603: GHC crashes on some code using StateT monad transformer Message-ID: <049.faef5c68395d742a3684db2c63ac8cd1@haskell.org> #8603: GHC crashes on some code using StateT monad transformer -------------------------------------+------------------------------------- Reporter: person1729 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Operating System: MacOS X Keywords: | Type of failure: Compile-time Architecture: x86_64 (amd64) | crash Difficulty: Unknown | Test Case: Attached Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- GHC version 7.6.3 on Mac OS X 10.9 crashes with the following message when compiling the attached file: {{{ ghc -c -v3 -dcore-lint DiscreteRandomVariableST.hs }}} {{{ Glasgow Haskell Compiler, Version 7.6.3, stage 2 booted by GHC version 7.4.2 Using binary package database: /Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/package.conf.d/package.cache Using binary package database: /Users/***/.ghc/x86_64-darwin-7.6.3/package.conf.d/package.cache hiding package binary-0.5.1.1 to avoid conflict with later version binary-0.7.1.0 hiding package Cabal-1.16.0 to avoid conflict with later version Cabal-1.18.1.2 wired-in package ghc-prim mapped to ghc- prim-0.3.0.0-d5221a8c8a269b66ab9a07bdc23317dd wired-in package integer-gmp mapped to integer- gmp-0.5.0.0-2f15426f5b53fe4c6490832f9b20d8d7 wired-in package base mapped to base-4.6.0.1-6c351d70a24d3e96f315cba68f3acf57 wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.8.0.0-c2c1b21dbbb37ace4b7dc26c966ec664 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: -static Created temporary directory: /var/folders/dg/lby0mtps13l9g0lry_dhsv1c0000gn/T/ghc13041_0 *** C pre-processor: '/sw/bin/gcc-4' '-E' '-undef' '-traditional' '-m64' '-fno-stack-protector' '-m64' '-I' '/Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/base-4.6.0.1/include' '-I' '/Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/include' '-D__GLASGOW_HASKELL__=706' '-Ddarwin_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Ddarwin_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-U __PIC__' '-D__PIC__' '-x' 'c' 'DiscreteRandomVariableST.hs' '-o' '/var/folders/dg/lby0mtps13l9g0lry_dhsv1c0000gn/T/ghc13041_0/ghc13041_0.hscpp' *** Checking old interface for main:DiscreteRandomVariableST: *** Parser: *** Renamer/typechecker: DiscreteRandomVariableST.hs:186:17: Couldn't match kind `* -> *' with `*' Expected type: [t1] -> StateT s RV t0 Actual type: [t1] -> StateT s RV t0 Kind incompatibility when matching types: [t_t14] :: * -> * [t1] :: * The function `lift'*** Deleting temp files: Deleting: /var/folders/dg/lby0mtps13l9g0lry_dhsv1c0000gn/T/ghc13041_0/ghc13041_0.s /var/folders/dg/lby0mtps13l9g0lry_dhsv1c0000gn/T/ghc13041_0/ghc13041_0.hscpp Warning: deleting non-existent /var/folders/dg/lby0mtps13l9g0lry_dhsv1c0000gn/T/ghc13041_0/ghc13041_0.s *** Deleting temp dirs: Deleting: /var/folders/dg/lby0mtps13l9g0lry_dhsv1c0000gn/T/ghc13041_0 ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-apple-darwin): kindFunResult ghc-prim:GHC.Prim.*{(w) tc 34d} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug}}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 9 10:13:27 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Dec 2013 10:13:27 -0000 Subject: [GHC] #8598: IO hack in demand analyzer gets in the way of CPR In-Reply-To: <046.257cc2180dce5fcae9e4dfcb90ad22aa@haskell.org> References: <046.257cc2180dce5fcae9e4dfcb90ad22aa@haskell.org> Message-ID: <061.fd8348c2c8f2016b8a01b19d5558f271@haskell.org> #8598: IO hack in demand analyzer gets in the way of CPR -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"7e5c115b88f0bae2e70f5d3fb7512c12a0f5744a/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="7e5c115b88f0bae2e70f5d3fb7512c12a0f5744a" Add testcase for #8598 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 9 10:25:49 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Dec 2013 10:25:49 -0000 Subject: [GHC] #8598: IO hack in demand analyzer gets in the way of CPR In-Reply-To: <046.257cc2180dce5fcae9e4dfcb90ad22aa@haskell.org> References: <046.257cc2180dce5fcae9e4dfcb90ad22aa@haskell.org> Message-ID: <061.39e787cd297ba6e7fa0342e2109001a0@haskell.org> #8598: IO hack in demand analyzer gets in the way of CPR -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: T8598 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * testcase: => T8598 Comment: My extended approach suggested above has issues. For example, what should be the `DmdResult` of a function parameter be? Lets consider {{{f x y = x `seq` y `seq` ...}}} and look at the `DmdResult` of `x`. Theoretically, we?d want to be conservative, and hence `DmdResult { mayExit = True, mayDiverge = True, cpr = NoCPR }`. But that would loose far too much strictness information, in particular we?d be lazy in `y`, which is undesirable. OTOH, if we assume `DmdResult { mayExit = False, mayDiverge = True, cpr = NoCPR }` for `x` it would be wrong if we pass something that can cleanly exit to `f`. `unsafePerformIO exitSuccess` would be such a thing ? but we do not really care about that, right? If we take the stance that clean exists should only really be happening when evaluating `IO` (and any other kind exiting is allowed to be reordered with other evaluations), then a still correct, but more precise analysis that we have right now is to use the elaborated lattice described in comment:5 and move the ''IO hack'' from case expressions to arguments: Use `DmdResult { mayExit = True, mayDiverge = True, cpr = NoCPR }` for arguments of `IO` type, and `DmdResult { mayExit = False, mayDiverge = True, cpr = NoCPR }` for all others. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 9 14:51:04 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Dec 2013 14:51:04 -0000 Subject: [GHC] #8598: IO hack in demand analyzer gets in the way of CPR In-Reply-To: <046.257cc2180dce5fcae9e4dfcb90ad22aa@haskell.org> References: <046.257cc2180dce5fcae9e4dfcb90ad22aa@haskell.org> Message-ID: <061.784c87ca5dbbdf5307bf89116d94d156@haskell.org> #8598: IO hack in demand analyzer gets in the way of CPR -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: T8598 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Simplified my fix in [http://git.haskell.org/ghc.git/shortlog/refs/heads/wip/T8598 `wip/T8598`] (did not add a new element to the lattice, rather added a simple unary function to defer a !DmdType when it occurs after an IO action). Code is currently validating, and will be pushed afterwards. This branch also contains a patch ?Rename topDmdType to nopDmdType?: > because topDmdType is ''not'' the top of the lattice, as it puts an > implicit absent demand on free variables, but Abs is the bottom of the > Usage lattice. > > Why nopDmdType? Becuase it is the demand of doing nothing: Everything > lazy, everything absent, no definite divergence. This ticket stays open to track the '''first''' issue SPJ mentioned in comment:2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 9 15:23:39 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Dec 2013 15:23:39 -0000 Subject: [GHC] #8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault In-Reply-To: <046.a1de52e736c53bf94deece978e2702d5@haskell.org> References: <046.a1de52e736c53bf94deece978e2702d5@haskell.org> Message-ID: <061.de845e06d2f7e1ee1355608548a5fa7b@haskell.org> #8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------+---------------------------------- Reporter: darchon | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by thoughtpolice): * owner: simonmar => thoughtpolice -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 9 15:26:25 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Dec 2013 15:26:25 -0000 Subject: [GHC] #8180: Template Haskell now requires -dynamic or -dynamic-too In-Reply-To: <047.1c653d82d918be711217186a104a0ee9@haskell.org> References: <047.1c653d82d918be711217186a104a0ee9@haskell.org> Message-ID: <062.1531161b1fc9d65d6342ea03f3ba871a@haskell.org> #8180: Template Haskell now requires -dynamic or -dynamic-too -------------------------------------+------------------------------------ Reporter: goldfire | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * owner: => thoughtpolice -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 9 15:28:13 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Dec 2013 15:28:13 -0000 Subject: [GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?) In-Reply-To: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> References: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> Message-ID: <062.7bd58c0ffe8bb5bab03de8cc3ac422fd@haskell.org> #7602: Threaded RTS performing badly on recent OS X (10.8?) -----------------------------------+---------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 7678 Blocking: | Related Tickets: -----------------------------------+---------------------------------- Comment (by simonpj): Highest priority to test what current situation is; but then we may or may not need to actually fix something. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 9 15:31:26 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Dec 2013 15:31:26 -0000 Subject: [GHC] #8366: haskeline Posix backend needs #include on Solaris In-Reply-To: <049.e865036198c31803d8a20d77075b82a9@haskell.org> References: <049.e865036198c31803d8a20d77075b82a9@haskell.org> Message-ID: <064.2fd6e9e3cec4d7f5b87bba798e3ae3e7@haskell.org> #8366: haskeline Posix backend needs #include on Solaris -------------------------------------+------------------------------------- Reporter: oddsignals | Owner: thoughtpolice Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.1 Component: libraries | Version: 7.7 (other) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Solaris | Difficulty: Easy (less than 1 Type of failure: Building GHC | hour) failed | Blocked By: Test Case: | Related Tickets: 8361 Blocking: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => infoneeded Comment: oddsignals, can you please comment on this ticket? Is this still needed for Solaris, or can you provide any more info? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 9 15:32:08 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Dec 2013 15:32:08 -0000 Subject: [GHC] #7396: Improve "parse error on input `$'" when TemplateHaskell PRAGMA not declared In-Reply-To: <045.6c29ee0e9781fd9f6a3d1232f4250abc@haskell.org> References: <045.6c29ee0e9781fd9f6a3d1232f4250abc@haskell.org> Message-ID: <060.e6206e2f516ea06a7e5653f9516649da@haskell.org> #7396: Improve "parse error on input `$'" when TemplateHaskell PRAGMA not declared ----------------------------------------+--------------------------- Reporter: ydewit | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.4.2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 9 15:32:28 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Dec 2013 15:32:28 -0000 Subject: [GHC] #8578: Improvements to SpinLock implementation In-Reply-To: <044.7d4d696b896537d8c685483f715ea999@haskell.org> References: <044.7d4d696b896537d8c685483f715ea999@haskell.org> Message-ID: <059.1209a4cff20719ddf285895c79008838@haskell.org> #8578: Improvements to SpinLock implementation -------------------------------------+------------------------------------ Reporter: parcs | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonmar): * owner: parcs => * status: patch => new Comment: Moving out of the patch state pending further investigation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 9 15:33:32 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Dec 2013 15:33:32 -0000 Subject: [GHC] #8453: segfault/assertion failure with multi-threaded profiling In-Reply-To: <043.88830003a4aab2e0f30d4506087b121b@haskell.org> References: <043.88830003a4aab2e0f30d4506087b121b@haskell.org> Message-ID: <058.85b1c68a1fb4c6798b07ebd908df7df1@haskell.org> #8453: segfault/assertion failure with multi-threaded profiling ----------------------------------+---------------------------------- Reporter: akio | Owner: thoughtpolice Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: Profiling | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: 8402 Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by thoughtpolice): * owner: akio => thoughtpolice * priority: normal => high * milestone: => 7.8.1 Comment: This still needs a testcase. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 9 15:34:21 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Dec 2013 15:34:21 -0000 Subject: [GHC] #4900: DEPENDS pragma In-Reply-To: <046.52f138a2609bf72d7f5381a2c64d358e@haskell.org> References: <046.52f138a2609bf72d7f5381a2c64d358e@haskell.org> Message-ID: <061.2a820bfa0529f12e58d9ee8623dc5344@haskell.org> #4900: DEPENDS pragma -------------------------------------+------------------------------------ Reporter: cdsmith | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: TH_Depends | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonmar): * owner: parcs => * status: patch => new Comment: Moving out of the patch state pending resolution of obstacles... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 9 15:35:46 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Dec 2013 15:35:46 -0000 Subject: [GHC] #8303: defer StackOverflow exceptions (rather than dropping them) when exceptions are masked In-Reply-To: <047.f5c1e98e88fb0e535a65a8bb76dcd836@haskell.org> References: <047.f5c1e98e88fb0e535a65a8bb76dcd836@haskell.org> Message-ID: <062.31a0f070e40c1c70a5de981bbee05410@haskell.org> #8303: defer StackOverflow exceptions (rather than dropping them) when exceptions are masked -------------------------------+------------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Runtime | Version: 7.7 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by simonmar): * owner: ezyang => * priority: normal => high * status: patch => new * milestone: => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 9 15:36:07 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Dec 2013 15:36:07 -0000 Subject: [GHC] #8303: defer StackOverflow exceptions (rather than dropping them) when exceptions are masked In-Reply-To: <047.f5c1e98e88fb0e535a65a8bb76dcd836@haskell.org> References: <047.f5c1e98e88fb0e535a65a8bb76dcd836@haskell.org> Message-ID: <062.614bbb964cc75a64754dbfe36ac5e6e4@haskell.org> #8303: defer StackOverflow exceptions (rather than dropping them) when exceptions are masked -------------------------------+------------------------------------------- Reporter: rwbarton | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Runtime | Version: 7.7 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by simonmar): * owner: => thoughtpolice -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 9 15:50:05 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Dec 2013 15:50:05 -0000 Subject: [GHC] #7684: cgrun071 segfaults In-Reply-To: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> References: <044.ae5c19c618d055ee0e8a21906a5056f9@haskell.org> Message-ID: <059.93017a63174186ccb0ec88c119438851@haskell.org> #7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by thoughtpolice): * status: patch => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 9 15:54:48 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Dec 2013 15:54:48 -0000 Subject: [GHC] #4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure In-Reply-To: <052.f68490df51931cf0218e339e7abda5be@haskell.org> References: <052.f68490df51931cf0218e339e7abda5be@haskell.org> Message-ID: <067.4cedcf6cd7cf29f2256b9aa242bb31ca@haskell.org> #4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure -------------------------------------+------------------------------------ Reporter: AntoineLatter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * owner: simonmar => * status: patch => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 9 15:55:10 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Dec 2013 15:55:10 -0000 Subject: [GHC] #4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure In-Reply-To: <052.f68490df51931cf0218e339e7abda5be@haskell.org> References: <052.f68490df51931cf0218e339e7abda5be@haskell.org> Message-ID: <067.e2c99d678c1951ea0e579ef2236195e3@haskell.org> #4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure -------------------------------------+------------------------------------ Reporter: AntoineLatter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: libraries/base | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * milestone: 7.8.1 => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 9 16:28:55 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Dec 2013 16:28:55 -0000 Subject: [GHC] #8598: IO hack in demand analyzer gets in the way of CPR In-Reply-To: <046.257cc2180dce5fcae9e4dfcb90ad22aa@haskell.org> References: <046.257cc2180dce5fcae9e4dfcb90ad22aa@haskell.org> Message-ID: <061.23203ddde0e099a515d59f9f5c1618a4@haskell.org> #8598: IO hack in demand analyzer gets in the way of CPR -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: T8598 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"def26d4335641b967940c56daac552b07b4efa6e/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="def26d4335641b967940c56daac552b07b4efa6e" Mark testcase for #8598 as not broken }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 9 16:29:40 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Dec 2013 16:29:40 -0000 Subject: [GHC] #8598: IO hack in demand analyzer gets in the way of CPR In-Reply-To: <046.257cc2180dce5fcae9e4dfcb90ad22aa@haskell.org> References: <046.257cc2180dce5fcae9e4dfcb90ad22aa@haskell.org> Message-ID: <061.15056cc9bc2f6db6cd9ecf7cc5a569ad@haskell.org> #8598: IO hack in demand analyzer gets in the way of CPR -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: T8598 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"a31cb5b07726f5739f6eac35cbb348fcd2d6b598/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a31cb5b07726f5739f6eac35cbb348fcd2d6b598" Do not forget CPR information after an IO action but do forget about certain divergence, if required. Fixes one part of ticket #8598. The added function (deferAfterIO) can maybe be merged with existing code, but given the ongoing work in the nested-cpr branch, I defer that work. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 9 18:46:54 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Dec 2013 18:46:54 -0000 Subject: [GHC] #8604: Some stack/vmem limits (ulimit) combinations causing GHC to fail Message-ID: <045.3fd2dc262c9d5efa9cc8ba9b4a4654dd@haskell.org> #8604: Some stack/vmem limits (ulimit) combinations causing GHC to fail ----------------------------------+---------------------------------- Reporter: clavin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Other Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- I have encountered a strange occurrence with GHC that was causing several GHC job failures on an SGE cluster. It turned out that there were other SGE users who needed an absurdly large stack size limit (set via 'ulimit -s') in the several gigabytes range. The default stack size limit had to be raised for the entire cluster. Any job that was run on a machine where the virtual memory limit was less than or equal to 2X the stack size limit, GHC would crash with the following message: ghc: failed to create OS thread: Cannot allocate memory I am running on GHC 7.6.3 with a 64-bit RedHat Enterprise OS, version 5.5. To reproduce the error, I was able to create the following test case: [ ~]$ ulimit -v unlimited [ ~]$ ulimit -s 10240 [ ~]$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 [ ~]$ ulimit -v 200000 [ ~]$ ulimit -s 100000 [ ~]$ ghc --version ghc: failed to create OS thread: Cannot allocate memory Several other programs work find using these settings, but GHC consistently has problems. Is this a fundamental issue with how GHC operates or can this be addressed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 9 18:51:02 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Dec 2013 18:51:02 -0000 Subject: [GHC] #8604: Some stack/vmem limits (ulimit) combinations causing GHC to fail In-Reply-To: <045.3fd2dc262c9d5efa9cc8ba9b4a4654dd@haskell.org> References: <045.3fd2dc262c9d5efa9cc8ba9b4a4654dd@haskell.org> Message-ID: <060.ae183cdf0cfcf48f5c8a4b9c6556d235@haskell.org> #8604: Some stack/vmem limits (ulimit) combinations causing GHC to fail ----------------------------------+---------------------------------- Reporter: clavin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Other | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by carter): ghc allocates the stack on the heap, so this may be tripping a corner case somehow... could you try it out with ghc HEAD to see if the problem is still there? theres been some changes to the default way stacks work. (that said, definitely worth understanding) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 9 18:59:02 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Dec 2013 18:59:02 -0000 Subject: [GHC] #8604: Some stack/vmem limits (ulimit) combinations causing GHC to fail In-Reply-To: <045.3fd2dc262c9d5efa9cc8ba9b4a4654dd@haskell.org> References: <045.3fd2dc262c9d5efa9cc8ba9b4a4654dd@haskell.org> Message-ID: <060.fe139fb9b21ac0931d9fbb492cbac6bc@haskell.org> #8604: Some stack/vmem limits (ulimit) combinations causing GHC to fail ----------------------------------+---------------------------------- Reporter: clavin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Other | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by clavin): Replying to [comment:1 carter]: > ghc allocates the stack on the heap, so this may be tripping a corner case somehow... > > could you try it out with ghc HEAD to see if the problem is still there? theres been some changes to the default way stacks work. (that said, definitely worth understanding) I compiled 7.6.3 from source, what would be the easiest way for me to do the same with GHC HEAD (I'm new around here)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 9 19:13:05 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Dec 2013 19:13:05 -0000 Subject: [GHC] #2528: documentation for nub and nubBy should be corrected, extended or removed. (was: nub not as reliable as nubBy) In-Reply-To: <047.2632c5cc755f3bbba48c2dd84ec254eb@haskell.org> References: <047.2632c5cc755f3bbba48c2dd84ec254eb@haskell.org> Message-ID: <062.79c6237e6494d3bc43f1f0d59daec1a4@haskell.org> #2528: documentation for nub and nubBy should be corrected, extended or removed. -----------------------------------+------------------------------------ Reporter: jdressel | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 6.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+------------------------------------ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 9 19:26:04 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Dec 2013 19:26:04 -0000 Subject: [GHC] #7056: GHCi loadArchive "libiconv.a":failed Unknown PEi386 section name `.drectve' In-Reply-To: <045.77f902a9eb98f7595f4855a4413508ee@haskell.org> References: <045.77f902a9eb98f7595f4855a4413508ee@haskell.org> Message-ID: <060.28ef86c7356626d9dfcd4472b1baa4ba@haskell.org> #7056: GHCi loadArchive "libiconv.a":failed Unknown PEi386 section name `.drectve' ----------------------------+---------------------------------------------- Reporter: songpp | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: loadArchive Unknown PEi386 Operating System: Windows | Architecture: x86 Type of failure: GHCi | Difficulty: Unknown crash | Blocked By: 3658 Test Case: | Related Tickets: #2487, #7103, #7889 Blocking: 8530 | ----------------------------+---------------------------------------------- Comment (by 3noch): I just got this trying to load `libHSpersistent-sqlite-1.2.1.a`. Any idea when it will be solved? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 9 19:50:55 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Dec 2013 19:50:55 -0000 Subject: [GHC] #8604: Some stack/vmem limits (ulimit) combinations causing GHC to fail In-Reply-To: <045.3fd2dc262c9d5efa9cc8ba9b4a4654dd@haskell.org> References: <045.3fd2dc262c9d5efa9cc8ba9b4a4654dd@haskell.org> Message-ID: <060.63bf8dff0e6955275c1519131f828127@haskell.org> #8604: Some stack/vmem limits (ulimit) combinations causing GHC to fail ----------------------------------+---------------------------------- Reporter: clavin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Other | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by carter): pretty much the exact same process. Make sure you have the newest versions of happy and alex installed, then follow the directions here https://ghc.haskell.org/trac/ghc/wiki/Building basically: clone the ghc repo ./sync-all get perl boot ./configure make -j # nb, this does an optimized build, so it take a while, edit the build to be a fast one, docs for that are in the build guide then test the ghc-stage2 in the ./inplace/bin folder -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 10 09:23:25 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Dec 2013 09:23:25 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.30a2673e311a195e914b11f4d1d0520e@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: nomeata Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8598 -------------------------------------+------------------------------------- Comment (by nomeata): Found one possible reason for the allocation increase: boyer2 was losing a no-let-escape, because the insight from `Note [CPR for sum types]` was not applied inside a nested CPR result. Fixed that now, nofibs are running. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 10 10:10:56 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Dec 2013 10:10:56 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.ac19f16d069ae94bdd0c37302fef25bd@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: nomeata Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8598 -------------------------------------+------------------------------------- Comment (by nomeata): Unfortunately, that was not it. The only visible change left is that `addtoLUT` in `Lisplikefns` is getting nestedly CPR?ed, without real gain (but also without loss, one would think). There is one other lead: With nested CPR, lots of "show" methods get a nested CPR property. E.g. the show method for `(,)` has now a return demand `tm2(tm(d),d)` (instead of `m2` as before), so the worker returns `(# GHC.Prim.Char#, [GHC.Types.Char] #)` instead of `(# GHC.Types.Char, [GHC.Types.Char] #)`, likely causing a re-boxing of the `(` character. I?ll disable nested CPR information inside a sum type to confirm this theory. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 10 11:11:36 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Dec 2013 11:11:36 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.4124eea2541271debf11bc766e8f1df9@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: nomeata Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8598 -------------------------------------+------------------------------------- Comment (by nomeata): It helps, i.e. removes all increases of Allocs (I don?t trust `cacheprof`, the allocations there seem to vary even from run to run): {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- cacheprof +0.0% +0.2% +1.5% +0.9% -1.8% gamteb +0.1% -0.2% 0.06 0.06 +0.0% infer +0.0% -1.2% 0.09 0.09 +0.0% pic +0.0% -0.6% 0.01 0.01 +0.0% -------------------------------------------------------------------------------- Min -0.0% -1.2% -5.2% -5.2% -4.0% Max +0.6% +0.2% +3.3% +3.0% +9.1% Geometric Mean +0.0% -0.0% +0.1% +0.1% +0.0% }}} So on the one hand: Nice, no regression due to nested CPR, and some improvements (although very minor ? is that even significant?) But the ?fix? is not well-targeted, it rather is a heuristic. Unfortunately, I don?t see anything smarter to do here if we do not do whole-program compilation, or do not provide multiple implementations of the the function with varying degrees of CPRness. An alternative, not well-aimed fix would be to zap the CPR property for all top-level constants (and not just for thunks). This would make CPR much more robust against allocation increase, but that would prevent a lot of CPR where we really want it, i.e. where the constant is on the cold path and the unshared `Int#` cell is worth having an unboxed result type (i.e. in a naive `fac` function). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 10 11:49:21 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Dec 2013 11:49:21 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.1f1408fa00dcac68bd44c597dfd21fe6@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: nomeata Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8598 -------------------------------------+------------------------------------- Comment (by nomeata): Here is a nother reason why nested CPR is not very successful: The requirement of definite termination is not easy to meet. One would think that the extended Euclidean algorithm is a good candidate for nested CPR: {{{ #!haskell extendedEu2 :: Int -> Int -> (Int, Int) extendedEu2 a 0 = (1, 0) extendedEu2 a b = (t, s - q * t) where (q, r) = quotRem a b (s, t) = extendedEu b r }}} but it is not: With a return type of `dm(d,dm(d))` we cannot do more than unbox the tuple. Now with a few iterations between the code and the core, one can find a strictness annotation that makes it work: With {{{ #!haskell extendedEu :: Int -> Int -> (Int, Int) extendedEu a 0 = (1, 0) extendedEu a b = let b' = s - q * t in b' `seq` (t, b') where (q, r) = quotRem a b (s, t) = extendedEu b r }}} we infer `dm(tm(d),tm(d))` and the worker gets type `GHC.Types.Int -> GHC.Prim.Int# -> (# GHC.Prim.Int#, GHC.Prim.Int# #)`. So likely nested CPR might help those who are careful to use strictness annotation and use strict data types (which some people are doing almost exclusively), but not a lot with the usual lazy programming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 10 12:06:13 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Dec 2013 12:06:13 -0000 Subject: [GHC] #8605: Alternative, guard-like syntax for view patterns Message-ID: <045.1743f62a4b303ec17137487f24324e6f@haskell.org> #8605: Alternative, guard-like syntax for view patterns ------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Implement the alternative syntax for view patterns described on the ViewPatternsAlternative wiki page -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 10 12:35:02 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Dec 2013 12:35:02 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.caec3d0a8fb522f25a1f8b4f4da519ea@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: nomeata Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8598 -------------------------------------+------------------------------------- Comment (by nomeata): The numbers are a bit more interesting if I enabled nested CPR inside ''unboxed'' tuples, i.e. in code involving IO or ST: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- banner +2.1% +0.1% 0.00 0.00 +0.0% compress2 +2.0% +0.1% +11.5% +9.8% +20.8% expert +2.1% +0.1% 0.00 0.00 +0.0% fibheaps +2.0% -0.3% 0.05 0.05 +0.0% fluid +2.5% +0.1% 0.01 0.01 +0.0% gamteb +2.1% -0.2% 0.06 0.06 +0.0% grep +2.0% +0.1% 0.00 0.00 +0.0% infer +2.0% -1.2% 0.09 0.09 +0.0% k-nucleotide +1.5% -6.9% +0.1% +0.2% +0.0% maillist +2.1% -0.3% 0.10 0.12 +0.0% pic +2.2% -0.5% 0.01 0.01 +0.0% rfib +2.1% +0.1% 0.03 0.03 +0.0% scs +2.3% +0.2% +1.0% +1.4% +0.0% tak +2.1% -0.1% 0.02 0.02 +0.0% treejoin +2.1% +0.1% +0.0% +0.0% +0.0% wave4main +2.1% +11.3% -0.5% +0.0% -7.1% -------------------------------------------------------------------------------- Min +1.5% -6.9% -13.2% -13.3% -33.3% Max +2.5% +11.3% +16.5% +16.0% +20.8% Geometric Mean +2.0% +0.0% +0.2% +0.3% -0.3% }}} One particular good result (`k-nucleotide`), and one bad `wave4main`, and otherwise a slight general improvement. The change in `k-nucleotide`?s core is too large to spot the reason for the improvement. Diffing the `-ddump-simpl` of `wave4main` shows only one change. It stems from this function {{{ #!haskell tabulate :: (Int -> x) -> (Int, Int) -> Array Int x tabulate f (l,u) = array (l,u) [(i, f i) | i <- [l..u]] }}} where in the (inlined) `array` a worker for `go` gets its return type changed from `(# GHC.Prim.State# s_aTM, GHC.Arr.Array GHC.Types.Int x_aqE #)` to `(# GHC.Prim.State# s_aTM, GHC.Prim.Int#, GHC.Prim.Int#, GHC.Prim.Int#, GHC.Prim.Array# x_aqE #)`. Which looks good, but the worker is tail-recursive, and the boxing in the wrapper is not cancelled at the use site of `go`, so there is nothing gain by moving the constructor applications from the worker to the wrapper. But some isolated testing indicates that this costs 96 bytes of allocation per run, so I doubt that this is the main cause for the 11% increase; there might be something hidden in the libraries. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 10 13:07:01 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Dec 2013 13:07:01 -0000 Subject: [GHC] #8604: Some stack/vmem limits (ulimit) combinations causing GHC to fail In-Reply-To: <045.3fd2dc262c9d5efa9cc8ba9b4a4654dd@haskell.org> References: <045.3fd2dc262c9d5efa9cc8ba9b4a4654dd@haskell.org> Message-ID: <060.d91ff582dc4356b4cf99a4d33845bfd5@haskell.org> #8604: Some stack/vmem limits (ulimit) combinations causing GHC to fail ----------------------------------+---------------------------------- Reporter: clavin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Other | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by int-e): Replying to [comment:1 carter]: > ghc allocates the stack on the heap, so this may be tripping a corner case somehow... There are two kinds of stacks. The STG stack (one per Haskell thread) is indeed allocated on the heap, grown dynamically, and its maximum size is governed by the '-K' RTS option. But each OS thread also has its own C stack and the size of that is determined by the stack size resource limit by default: ({{{createOSThread()}}} in {{{rts/posix/OSThreads.c}}} uses {{{pthread_create()}}} with no specific thread attributes. Quoting {{{man pthread_create}}}: {{{ On Linux/x86-32, the default stack size for a new thread is 2 megabytes. Under the NPTL threading implementation, if the RLIMIT_STACK soft resource limit at the time the program started has any value other than "unlimited", then it determines the default stack size of new threads. }}} Other implementations may differ. I'm not sure whether or how this should be dealt with by ghc. In some circumstances, a large C stack is required (depending on used foreign libraries), and currently the soft stack resource limit is the knob to turn in that case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 10 13:08:01 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Dec 2013 13:08:01 -0000 Subject: [GHC] #8502: Document a surprising {{{unsafeDupablePerformIO}}} limitation. In-Reply-To: <044.489edd9a621286a2f23856fcc4df99d4@haskell.org> References: <044.489edd9a621286a2f23856fcc4df99d4@haskell.org> Message-ID: <059.6081f552e8d226ee8054623146ded04b@haskell.org> #8502: Document a surprising {{{unsafeDupablePerformIO}}} limitation. -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Documentation | Difficulty: Easy (less than 1 bug | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by int-e): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 10 13:43:55 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Dec 2013 13:43:55 -0000 Subject: [GHC] #8606: Fix whitespaces in rts/sm/Scav.c Message-ID: <047.6a57100d3db9294020694d3e91dba13b@haskell.org> #8606: Fix whitespaces in rts/sm/Scav.c ------------------------------------+------------------------------------- Reporter: Tarrasch | Owner: simonmar Type: task | Status: new Priority: lowest | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 10 13:47:28 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Dec 2013 13:47:28 -0000 Subject: [GHC] #8606: Fix whitespaces in rts/sm/Scav.c In-Reply-To: <047.6a57100d3db9294020694d3e91dba13b@haskell.org> References: <047.6a57100d3db9294020694d3e91dba13b@haskell.org> Message-ID: <062.196eb89448dd6c6ff66068b2384bc60e@haskell.org> #8606: Fix whitespaces in rts/sm/Scav.c -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: simonmar Type: task | Status: patch Priority: lowest | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by Tarrasch): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 10 14:56:28 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Dec 2013 14:56:28 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.54daad3392f09455799f62e9793ccb39@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: nomeata Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8598 -------------------------------------+------------------------------------- Comment (by nomeata): Trac seems to think I write too much, just lost a somewhat long text here :-(. I was explaining why nested CPR kills a let-no-espcape in this code taken from `scs`?s `LinearAlgebra`: {{{ #!haskell v_zipWith :: (a -> b -> c) -> Array Int a -> Array Int b -> Array Int c v_zipWith f a b | compatible = listArray (bounds a) (zipWith f (elems a) (elems b)) | otherwise = error "error" where compatible = bounds a == bounds b }}} Point taken, I?ll be brief: CPR can kill the no-let-escape property; hence more CPR kills more of that. The problem occurs if the `$j` gets a more detailed CPR type than the expression it is part of, or the expression is somewhere where CPR w/w cannot happen (e.g. in an argument to `runStRep`). This problem is not new and some work-arounds for it exist in the current code (`[CPR for Sun types]`). But maybe this needs a generally better story. (Sidenote: Inlining `runSTRep` would have helped here, but was disabled by simonmar in 920dbbddf57ff02e0734943bb93dd4cecc5568e0/base.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 10 15:00:09 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Dec 2013 15:00:09 -0000 Subject: [GHC] #8607: Invalid location reported for type constructors Message-ID: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> #8607: Invalid location reported for type constructors ------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Given {{{ module Example where data T = MkT }}} The locations as reported in 7.4 and 7.7 are different: * In 7.4 the ADT is represented as a `TyData`, itself part of an `HsGroup`. The `TyData` contains a `Located Name`; the location of this name is reported correctly as 3:6. The `SrcSpan` associated with the `Name` itself (which represents the def site) is also reported as 3:6, which is dubious. * In 7.8 the ADT is represented as a `DataDecl` (part of ` TyClGroup` inside a `HsGroup`). As before, the `DataDecl`contains a `Located Name`; the location now however is 3:1-12, which doesn't make sense. The def site associated with the name itself is also 3:1-12, which ''does'' make sense. It seems that when the def site was fixed, it also changed the location of the identifier itself. These two are separate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 10 15:48:32 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Dec 2013 15:48:32 -0000 Subject: [GHC] #8607: Invalid location reported for type constructors In-Reply-To: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> References: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> Message-ID: <059.2032b74c6acbe34154d961054d084d74@haskell.org> #8607: Invalid location reported for type constructors -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by edsko): Actually, the def-site as reported by 7.4 is correct (it's the position where the id is defined, not the span of the definition proper). So I think 7.4 is correct about both locations, and 7.7 wrong about both. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 10 17:50:16 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Dec 2013 17:50:16 -0000 Subject: [GHC] #8566: Panic with kindFunResult In-Reply-To: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> References: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> Message-ID: <061.e81b1205e43ea3d59949f44367cb23bd@haskell.org> #8566: Panic with kindFunResult -------------------------------------+------------------------------------ Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"755823126f4f58b74f2bb783dc683197273f3474/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="755823126f4f58b74f2bb783dc683197273f3474" Do not generate given kind-equalities (fix Trac #8566) This is a long-standing bug. We were generating a Given equality between kind variables, and (at least until we support kind coercions) we can't do that. The fix is to drop such Given equalities entirely. That may mean we can't prove some things, but that's fair enough -- the current proof language can't express such proofs. See Note [Do not create Given kind equalities] in TcSMonad }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 10 17:54:21 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Dec 2013 17:54:21 -0000 Subject: [GHC] #8566: Panic with kindFunResult In-Reply-To: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> References: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> Message-ID: <061.22b7e9e028e25748272a34bf4ea8d4da@haskell.org> #8566: Panic with kindFunResult -------------------------------------+------------------------------------ Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"a6e35a07d6d48ce782c5473c03cc09da996e1986/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="a6e35a07d6d48ce782c5473c03cc09da996e1986" Test Trac #8566 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 10 17:54:56 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Dec 2013 17:54:56 -0000 Subject: [GHC] #8566: Panic with kindFunResult In-Reply-To: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> References: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> Message-ID: <061.d1a31a559aad764f093b42abcba5f811@haskell.org> #8566: Panic with kindFunResult -------------------------------------+------------------------------------ Reporter: dreixel | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Thank you! This was a real, and long-standing bug. Fixed. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 10 17:55:12 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Dec 2013 17:55:12 -0000 Subject: [GHC] #8566: Panic with kindFunResult In-Reply-To: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> References: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> Message-ID: <061.bab7e5d536e5cf4f0681cb5ee4c595ac@haskell.org> #8566: Panic with kindFunResult -------------------------------------+------------------------------------ Reporter: dreixel | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: polykinds/T8566 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * testcase: => polykinds/T8566 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 10 23:42:42 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Dec 2013 23:42:42 -0000 Subject: [GHC] #8608: internal error: ARR_WORDS object entered! Message-ID: <046.2530ebd4673d226821907dc5ab5b8d3c@haskell.org> #8608: internal error: ARR_WORDS object entered! ----------------------------+---------------------------------- Reporter: Rothiph | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+---------------------------------- I'm using Windows 8.1 64-bit, the latest Windows SDK, and the latest Haskell Platform to rebuild a project. This project was previously building on Windows 7 64-bit with the same HP and a previous version of the Windows SDK. Source code for the project was unchanged, but my .cabal file was updated with different "extra-lib-dirs", "include-dirs", and "extra-libraries" fields. When running this program after a `cabal build` I see the following error: Segmentation fault/access violation in generated code Using print statements I was able to locate the error as occurring during a call to an external DLL function. I would assume this is a bug in my own code. Access violations are expected when misusing FFI, after all. However, I get a different error when compiling with profiling, and then executing with `Main.exe +RTS -xc`: Main.exe: internal error: ARR_WORDS object entered! (GHC version 7.6.3 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Coming up with a minimal example would take time, but I can do that if someone thinks there is a possibility of this being a GHC bug. Is it possible for this message to appear under normal circumstances by programmer error? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 11 00:02:48 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Dec 2013 00:02:48 -0000 Subject: [GHC] #8491: Make BlockAlloc.c comments slightly more accurate In-Reply-To: <045.5e14ff3a04e439f527241772d8ef521e@haskell.org> References: <045.5e14ff3a04e439f527241772d8ef521e@haskell.org> Message-ID: <060.2b531cb7921871dad90c9bd2f3fb5c66@haskell.org> #8491: Make BlockAlloc.c comments slightly more accurate -------------------------------------+------------------------------------ Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: patch Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by ezyang): * keywords: => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 11 01:11:19 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Dec 2013 01:11:19 -0000 Subject: [GHC] #8609: Clean up block allocator Message-ID: <045.da9b454c1e9861c91a9a3c65db94c556@haskell.org> #8609: Clean up block allocator -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 7.7 Keywords: patch | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Runtime Difficulty: Easy (less than 1 | performance bug hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- For fun, I was reimplementing GHC's block allocator in Rust, and I noticed that there are a number of things the current block allocator code does that result in extra, unnecessary work: * Upon a perfect match, `alloc_mega_group` initializes the returned block group (`initGroup`). This is unnecessary, because the caller of `alloc_mega_group` is responsible for initializing the block groups. * The `initGroup` function uses the `blocks` to figure out how many block descriptors it needs to initialize. However, in the case of a multi- megablock group, blocks will larger than BLOCKS_PER_MBLOCK, so this process will march into the first block and write information to block descriptors which will be later be overwritten by the user data. So, `initGroup` should cap at the block descriptors of the first megablock. One can go even further: if a block group spans multiple megablocks, then in practice, the only block descriptor we care about is the very first one, since we're not allowed to have internal GC'd pointers to the block group (as not every address in the group has a valid bdescr associated with it). * The commentary should add a bit about mblock groups. Essentially, the mblock free list has a different set of invariants: the first mblock's start pointers are guaranteed to be initialized (the mblock was `initMBlock` 'd), and the blocks and link fields of the first bdescr will be something appropriate; there are no other guarantees. Here are the proposed functional changes (obviously some extra documentation is necessary; replace the XXX marked expression with BLOCKS_PER_MBLOCK if you want to do the more conservative changes for larger than mblock block chains): {{{ diff --git a/rts/sm/BlockAlloc.c b/rts/sm/BlockAlloc.c index 18c167f..33530d8 100644 --- a/rts/sm/BlockAlloc.c +++ b/rts/sm/BlockAlloc.c @@ -170,7 +170,7 @@ initGroup(bdescr *head) bdescr *bd; W_ i, n; - n = head->blocks; + n = head->blocks > BLOCKS_PER_MBLOCK ? 1 /* XXX */ : head->blocks; head->free = head->start; head->link = NULL; for (i=1, bd = head+1; i < n; i++, bd++) { @@ -278,7 +278,6 @@ alloc_mega_group (StgWord mblocks) } else { free_mblock_list = bd->link; } - initGroup(bd); return bd; } else if (bd->blocks > n) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 11 08:17:16 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Dec 2013 08:17:16 -0000 Subject: [GHC] #8609: Clean up block allocator In-Reply-To: <045.da9b454c1e9861c91a9a3c65db94c556@haskell.org> References: <045.da9b454c1e9861c91a9a3c65db94c556@haskell.org> Message-ID: <060.076af8742028b4a424896e46268d7c04@haskell.org> #8609: Clean up block allocator -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: patch Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Easy (less than 1 performance bug | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by simonmar): Looks good to me! Nice catch for the duplicate `initGroup` call. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 11 11:47:00 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Dec 2013 11:47:00 -0000 Subject: [GHC] #8610: Rebuild on a definition-based granularity Message-ID: <048.61d473ef50838fa5675d6fa359c62ebe@haskell.org> #8610: Rebuild on a definition-based granularity ------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Currently, GHC rebuilds modules whose mtime suggests they changed, and all dependent modules. This rebuilds *far* more than is actually necessary due to the change. For example, if a single definition changed in a module, only that definition needs to be rebuilt, and very few of the definitions in the dependent modules probably depend on it, so only they ought to be rebuilt. Another example, is temporarily checking out a different branch, and then going back to the master branch. In this case, the mtimes of many modules will change, but the content will remain the same. If definition-granularity changes were detected, rather than module- granularity, this scenario will rebuild nothing. This improvement could shorten the development cycle of all Haskell projects significantly, making Haskell a significantly more productive language to use on larger projects. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 11 12:01:10 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Dec 2013 12:01:10 -0000 Subject: =?utf-8?b?W0dIQ10gIzg2MTE6IG5vZmli4oCZcyBjYWNoZXByb2bigJlzIGFs?= =?utf-8?q?locations_nondeterminisitic?= Message-ID: <046.9452bfe64045e297fcab99166dcd73b9@haskell.org> #8611: nofib?s cacheprof?s allocations nondeterminisitic -----------------------------------------+--------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark suite | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: -----------------------------------------+--------------------------------- This seems to be neither expected nor desired, and hence worth investigating: {{{ ./cacheprof +RTS -t <> ./cacheprof +RTS -t <> }}} The allocations numbers change, when they shoudn?t. Reproduced with 7.6.3 and current HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 11 12:07:35 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Dec 2013 12:07:35 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICM4NjExOiBub2ZpYuKAmXMgY2FjaGVwcm9m4oCZ?= =?utf-8?q?s_allocations_nondeterminisitic?= In-Reply-To: <046.9452bfe64045e297fcab99166dcd73b9@haskell.org> References: <046.9452bfe64045e297fcab99166dcd73b9@haskell.org> Message-ID: <061.d10ab661e93996de0bc8a14ecf9e98b6@haskell.org> #8611: nofib?s cacheprof?s allocations nondeterminisitic ------------------------------------------+-------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark suite | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Comment (by nomeata): I could not find the cause immediately, so I?ll report my partial findings here. * It is not the IO part. Inlining the input as one big string, and skipping the output, does not make the symptom disappear. * Ticky-ticky profiling yields identical results for the cacheprof modules, the only difference is in the global counters (`HEAP_CHK_ctr` and `STK_CHK_ctr`) to be precise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 11 12:39:13 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Dec 2013 12:39:13 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICM4NjExOiBub2ZpYuKAmXMgY2FjaGVwcm9m4oCZ?= =?utf-8?q?s_allocations_nondeterminisitic?= In-Reply-To: <046.9452bfe64045e297fcab99166dcd73b9@haskell.org> References: <046.9452bfe64045e297fcab99166dcd73b9@haskell.org> Message-ID: <061.650664e1277dd7965900ab29a76354a9@haskell.org> #8611: nofib?s cacheprof?s allocations nondeterminisitic ------------------------------------------+-------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark suite | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Comment (by nomeata): The cause does not seem to be tied to a particular part of the code: Luckily, `doFile` has a very plain pipeline. The symptoms disappear when I stop at processing `with_ccs` and appear if I go until `with_synth_2`. But if I read `with_css` from a file instead of calculating it and only do the `synth_2` call, the result also becomes deterministic. Tricky. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 11 14:10:48 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Dec 2013 14:10:48 -0000 Subject: [GHC] #8607: Invalid location reported for type constructors In-Reply-To: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> References: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> Message-ID: <059.8a33aa401c7e3981060ffd0a5c9988de@haskell.org> #8607: Invalid location reported for type constructors -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by edsko): The same problem goes for class definitions; the location of `C` in {{{ class C a where f :: a -> a }}} is reported as the span of the entire class, rather than the span of just the identifier. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 11 14:30:47 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Dec 2013 14:30:47 -0000 Subject: [GHC] #8607: Invalid location reported for type constructors In-Reply-To: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> References: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> Message-ID: <059.a1a165810156bd06c5ae7a659032cf3a@haskell.org> #8607: Invalid location reported for type constructors -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by edsko): .. and the same for type synonyms .. Location of `Foo` in {{{ type Foo = Int }}} is reported as the entire synonym declaration (1-14 instead of 6-8). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 11 14:39:11 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Dec 2013 14:39:11 -0000 Subject: [GHC] #8607: Invalid location reported for type constructors In-Reply-To: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> References: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> Message-ID: <059.141742b6a2dd58e68442faff6195dff8@haskell.org> #8607: Invalid location reported for type constructors -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by edsko): .. and type families .. Location of `Bar` in {{{ type family Bar a }}} is reported as the entire line (type family instances do appear to be correct). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 12 17:34:52 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Dec 2013 17:34:52 -0000 Subject: [GHC] #8601: runghc from standard input and --ghc-args In-Reply-To: <045.11cb225cfe1bdf84af2a31b9e73fe50d@haskell.org> References: <045.11cb225cfe1bdf84af2a31b9e73fe50d@haskell.org> Message-ID: <060.85b247c16ad6f7a2d1e16eb0d38a16e6@haskell.org> #8601: runghc from standard input and --ghc-args -------------------------------------+------------------------------------ Reporter: wuzzeb | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by wuzzeb): * status: new => patch Comment: I fixed the bug in the attached patch. I also kept around the ability to use --ghc-arg=--ghc-arg= as a prefix for backwards compatibility, although I have no strong feelings so if you want to take it out that is fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 12 20:41:32 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Dec 2013 20:41:32 -0000 Subject: [GHC] #8608: internal error: ARR_WORDS object entered! In-Reply-To: <046.2530ebd4673d226821907dc5ab5b8d3c@haskell.org> References: <046.2530ebd4673d226821907dc5ab5b8d3c@haskell.org> Message-ID: <061.d79d362b8df4cdfecd088cca9ca97916@haskell.org> #8608: internal error: ARR_WORDS object entered! ----------------------------------+--------------------------- Reporter: Rothiph | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+--------------------------- Comment (by Rothiph): I'm going to close this. The access violation must be caused by the way I am making the foreign call. I get the expected result when the project is loaded in ghci, but not when everything is compiled. Perhaps there is a linker problem I need to sort out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 12 20:41:50 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Dec 2013 20:41:50 -0000 Subject: [GHC] #8608: internal error: ARR_WORDS object entered! In-Reply-To: <046.2530ebd4673d226821907dc5ab5b8d3c@haskell.org> References: <046.2530ebd4673d226821907dc5ab5b8d3c@haskell.org> Message-ID: <061.c3d9138aa7b27416970943fcddb42935@haskell.org> #8608: internal error: ARR_WORDS object entered! ----------------------------------+--------------------------- Reporter: Rothiph | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: invalid | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+--------------------------- Changes (by Rothiph): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 12 23:23:19 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Dec 2013 23:23:19 -0000 Subject: [GHC] #8608: internal error: ARR_WORDS object entered! In-Reply-To: <046.2530ebd4673d226821907dc5ab5b8d3c@haskell.org> References: <046.2530ebd4673d226821907dc5ab5b8d3c@haskell.org> Message-ID: <061.80bcdf65a526501ae22287c944311f23@haskell.org> #8608: internal error: ARR_WORDS object entered! ----------------------------------+--------------------------- Reporter: Rothiph | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: invalid | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+--------------------------- Comment (by Rothiph): I think I understand what was going on, and will explain in case anyone else has trouble calling into .dll files. Note that some of this may be inaccurate. The Win32 DLL I'm trying to load is dhcpsapi.dll. I can access functions using run-time dynamic loading (by calling LoadLibrary), but if I attempt to call them using load-time dynamic loading an access violation is triggered. GHC on windows relies on mingw. When you specify a dll to load using the "extra-libraries" option in the cabal file, the standard Windows search mechanism is not used. Each common system dll has a corresponding .a file under "C:\Program Files (x86)\Haskell Platform\2013.2.0.0\mingw\lib". My problem was that mingw does not include an .a file for dhcpsapi. Trying to load it natively worked in the sense that the project was able to compile and link, but something went wrong at runtime. I suspect this has something to do with the fact that dhcpsapi.dll depends on other system dlls which mingw has already linked in. My previous computer must have already had mingw-w64 installed, which does include dhcpsapi.a. Being earlier in my PATH, this variant of mingw was being used by ghc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 12 23:53:56 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Dec 2013 23:53:56 -0000 Subject: [GHC] #8612: Error message "not in scope" on missing 'deriving' Message-ID: <044.5643ce4d7d2bc8ece84c422672af73da@haskell.org> #8612: Error message "not in scope" on missing 'deriving' ------------------------------------+------------------------------------- Reporter: mirpa | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.4.1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Incorrect definition like: {{{ module Der where data A = A { a :: Int } (Show) -- missing deriving }}} gives error message: {{{ der.hs:3:14: Not in scope: `a' }}} I had bigger data structure, where I concentrated on {{{a :: Int}}} part between parentheses trying to figure out why {{{a}}} is not defined. Missing {{{deriving}}} could easily escape your eye in such case. I would like to get something like: {{{ der.hs:4:14: Unexpected `(' }}} For instance Hugs says: {{{ ERROR "der.hs":4 - Syntax error in input (unexpected `(') }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 13 10:37:17 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Dec 2013 10:37:17 -0000 Subject: [GHC] #8607: Invalid location reported for type constructors In-Reply-To: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> References: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> Message-ID: <059.38395f2f304b4c15ee583d13e7fe39f8@haskell.org> #8607: Invalid location reported for type constructors -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by edsko): Hmmm, this appears to be (partly?) intentional -- https://ghc.haskell.org/trac/ghc/changeset/174577912de7a21b8fe01881a28f5aafce02b92e/ghc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 13 12:30:14 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Dec 2013 12:30:14 -0000 Subject: [GHC] #8566: Panic with kindFunResult In-Reply-To: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> References: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> Message-ID: <061.ea01bb8bf0480aaf94cfaa714551db12@haskell.org> #8566: Panic with kindFunResult -------------------------------------+------------------------------------ Reporter: dreixel | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: polykinds/T8566 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by dreixel): I suspect this fix makes the following code fail to compile with HEAD: {{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeOperators #-} data Field = forall k. APP k [Field] data InField (u :: Field) :: * where A :: { unA :: AppVars t (ExpandField args) } -> InField (APP t args) -- Without the selector, the program compiles -- A :: AppVars t (ExpandField args) -> InField (APP t args) type family ExpandField (args :: [Field]) :: [*] type family AppVars (t :: k) (vs :: [*]) :: * }}} Note that simply removing the selector `unA` fixes the problem. The code compiles with 7.6. Is this a regression, or is it the expected behaviour?... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 13 13:25:39 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Dec 2013 13:25:39 -0000 Subject: [GHC] #8613: simplifier ticks exhausted Message-ID: <044.3c96d4abc261f1969033a0de42af80e6@haskell.org> #8613: simplifier ticks exhausted ----------------------------------+---------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------- (Sent by chrisreade at mac.com ) Compiler giving up with simplifier ticks exhausted. Large amount of simplification may be going on to cause this. The problem goes away when using -fsimpl-tick-factor=1000 and the code runs. This is the session output without the flag (asking to have bug reported): chris$ ghc -O2 -rtsopts RedBlackStencilOpt.hs -v Glasgow Haskell Compiler, Version 7.6.3, stage 2 booted by GHC version 7.4.2 Using binary package database: /Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/package.conf.d/package.cache Using binary package database: /Users/chris/.ghc/x86_64-darwin-7.6.3/package.conf.d/package.cache hiding package binary-0.5.1.1 to avoid conflict with later version binary-0.6.4.0 hiding package Cabal-1.16.0 to avoid conflict with later version Cabal-1.18.1.1 wired-in package ghc-prim mapped to ghc- prim-0.3.0.0-d5221a8c8a269b66ab9a07bdc23317dd wired-in package integer-gmp mapped to integer- gmp-0.5.0.0-2f15426f5b53fe4c6490832f9b20d8d7 wired-in package base mapped to base-4.6.0.1-6c351d70a24d3e96f315cba68f3acf57 wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.8.0.0-c2c1b21dbbb37ace4b7dc26c966ec664 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: -static *** Chasing dependencies: Chasing modules from: *RedBlackStencilOpt.hs Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2013-12-13 13:12:37 UTC ms_mod = main:RedBlackStencilOpt, ms_textual_imps = [import (implicit) Prelude, import Data.Array.Repa.Stencil.Dim2 as A, import Data.Array.Repa.Stencil as A, import Data.Array.Repa as A] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file RedBlackStencilOpt.hs Created temporary directory: /var/folders/dz/m1mks1yn1bsft72zgh105sw40000gn/T/ghc93155_0 *** Checking old interface for main:RedBlackStencilOpt: [1 of 1] Compiling RedBlackStencilOpt ( RedBlackStencilOpt.hs, RedBlackStencilOpt.o ) *** Parser: *** Renamer/typechecker: *** Simplify: *** CorePrep: *** ByteCodeGen: Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. *** gcc: '/usr/bin/gcc' '-m64' '-fno-stack-protector' '-m64' '-L/Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/base-4.6.0.1' '--print-file-name' 'libiconv.dylib' Loading package base ... linking ... done. Loading package pretty-1.1.1.0 ... linking ... done. Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package containers-0.5.0.0 ... linking ... done. Loading package old-locale-1.0.0.5 ... linking ... done. Loading package time-1.4.0.1 ... linking ... done. Loading package random-1.0.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package QuickCheck-2.6 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package primitive-0.5.0.1 ... linking ... done. Loading package vector-0.10.0.1 ... linking ... done. Loading package repa-3.2.3.3 ... linking ... done. *** Simplify: *** CorePrep: *** ByteCodeGen: *** Desugar: Result size of Desugar (after optimization) = {terms: 900, types: 1,810, coercions: 340} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 834, types: 1,757, coercions: 567} Result size of Simplifier iteration=2 = {terms: 830, types: 1,721, coercions: 567} Result size of Simplifier = {terms: 830, types: 1,721, coercions: 567} *** Specialise: Result size of Specialise = {terms: 830, types: 1,721, coercions: 567} *** Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}): Result size of Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}) = {terms: 993, types: 2,131, coercions: 567} *** Float inwards: Result size of Float inwards = {terms: 993, types: 2,131, coercions: 567} *** Simplifier: *** Deleting temp files: Deleting: /var/folders/dz/m1mks1yn1bsft72zgh105sw40000gn/T/ghc93155_0/ghc93155_0.s Warning: deleting non-existent /var/folders/dz/m1mks1yn1bsft72zgh105sw40000gn/T/ghc93155_0/ghc93155_0.s *** Deleting temp dirs: Deleting: /var/folders/dz/m1mks1yn1bsft72zgh105sw40000gn/T/ghc93155_0 ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-apple-darwin): Simplifier ticks exhausted When trying RuleFired Class op szipWith To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 60402 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 13 15:48:21 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Dec 2013 15:48:21 -0000 Subject: [GHC] #8607: Invalid location reported for type constructors In-Reply-To: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> References: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> Message-ID: <059.785979ba32b2a4e9169a7001d0a2021b@haskell.org> #8607: Invalid location reported for type constructors -------------------------------------+------------------------------------ Reporter: edsko | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by goldfire): * owner: => goldfire Comment: Yes, it does appear to be somewhat intentional. But, it looks like some plumbing change in !TcTyClsDecls could restore the old behavior. (I'm thinking of returning `TcM [Located TyThing]` from `tcTyClDecl`.) I can take a look at this next week. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 13 15:52:24 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Dec 2013 15:52:24 -0000 Subject: [GHC] #8607: Invalid location reported for type constructors In-Reply-To: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> References: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> Message-ID: <059.f40af2a1ac976dd80bdcf1b05c06ed98@haskell.org> #8607: Invalid location reported for type constructors -------------------------------------+------------------------------------ Reporter: edsko | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by edsko): FYI, I sent the following email to SPJ, but he won't be back until next year: In the commit message you say "The only wrinkle is that, since we don't have the original declaration, we don't have its `SrcSpan` to put in the error message". But the function you are talking about is checkValidDecl, right? And that takes a Located Name as argument -- would it be possible to use the nameSrcSpan of the Name instead of the error message? I.e., have the def site of the Name be the entire declaration of the type, but the location of the identifier itself still the actual location of the identifier? Changing the `SrcSpan` associated with the identifier itself is troublesome for IDEs that want to know information about identifiers at particular locations. I'm not 100% how to go about this though, because the parser obviously generates a `RdrName`, not a Name, so we don't yet have the distinction between the location of a name (Located Name) and its nameSrcSpan. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 13 16:25:27 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Dec 2013 16:25:27 -0000 Subject: [GHC] #8607: Invalid location reported for type constructors In-Reply-To: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> References: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> Message-ID: <059.a97f5b42cd21e3d6acf0b8acdc1fc13d@haskell.org> #8607: Invalid location reported for type constructors -------------------------------------+------------------------------------ Reporter: edsko | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): I'm not sure what chunk of code you're talking about. While I agree that a `Located Name` is redundant, I don't see how that helps us here. It seems to me that the function of interest is `checkValidTyCl`, which just takes a `TyThing`, devoid of any location information other than what is stored in the `n_loc` field of `Name`s. By passing in an extra location (by using `Located TyThing`), we can get good error messages and proper spans on identifiers. I do feel a little dirty decorating the Core-ish `TyThing` with the Haskell-ish `Located`, but I think this is a reasonable place to do so. Other suggestions are welcome. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 13 16:29:43 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Dec 2013 16:29:43 -0000 Subject: [GHC] #8607: Invalid location reported for type constructors In-Reply-To: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> References: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> Message-ID: <059.05f3ec563e43a9ab69d43e53b2864886@haskell.org> #8607: Invalid location reported for type constructors -------------------------------------+------------------------------------ Reporter: edsko | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by edsko): Well I'm not familiar at all with this code, so I may be talking nonsense; I just wanted to point out that a `Located Name` is _not_ redundant: a `Located Name` contains two locations, and that's exactly right: one if the location of the identifier, and the other is the def span of whatever the identifier is referring to. The change in this commit changed _both_ of those locations to be the span of the entire type declaration; it seems to be that it ought to be sufficient to change only the `nameSrcSpan` but not the location of the identifier itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 13 17:44:32 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Dec 2013 17:44:32 -0000 Subject: [GHC] #5539: GHC panic - Simplifier ticks exhausted In-Reply-To: <042.6c9e0d5ccc72cfd48edcd6c26bf7a923@haskell.org> References: <042.6c9e0d5ccc72cfd48edcd6c26bf7a923@haskell.org> Message-ID: <057.c9225d7336ef7b12627657211fd16251@haskell.org> #5539: GHC panic - Simplifier ticks exhausted ---------------------------------------+---------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: Compiler | Version: 7.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by ghorn): * cc: gregmainland@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 13 20:07:23 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Dec 2013 20:07:23 -0000 Subject: [GHC] #8612: Error message "not in scope" on missing 'deriving' In-Reply-To: <044.5643ce4d7d2bc8ece84c422672af73da@haskell.org> References: <044.5643ce4d7d2bc8ece84c422672af73da@haskell.org> Message-ID: <059.89e118b3c91a502bf6401a630e0fac52@haskell.org> #8612: Error message "not in scope" on missing 'deriving' -------------------------------------+------------------------------------ Reporter: mirpa | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by monoidal): * status: new => closed * resolution: => fixed Comment: In HEAD you get a bit better message {{{ Der.hs:3:12: Record syntax is illegal here: {a :: Int} Der.hs:3:14: Not in scope: ?a? }}} It's not ideal, but IMO it gives a good hint that the specific part `a::Int` is not the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 15 23:46:42 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Dec 2013 23:46:42 -0000 Subject: [GHC] #8614: Duplicate symbol error when loading text twice Message-ID: <042.f86f42b094fe0faf9d18aa4da57dfc8a@haskell.org> #8614: Duplicate symbol error when loading text twice ------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- We are developing some FFI binding to some Kinect Camera library, and came across the following: {{{ GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> import Honi Prelude Honi> import Honi.Types Prelude Honi Honi.Types> initialize 2 Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package text-0.11.3.1 ... linking ... done. Loading package honi-0.1.0.0 ... can't load .so/.DLL for: libfreenect.so (libfreenect.so: cannot open shared object file: No such file or directory) Prelude Honi Honi.Types> Right [d] <- getDeviceList Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package text-0.11.3.1 ... GHCi runtime linker: fatal error: I found a duplicate definition for symbol __stginit_textzm0zi11zi3zi1_DataziText whilst processing object file /home/niklas/.cabal/lib/x86_64-linux- ghc-7.6.3/text-0.11.3.1/libHStext-0.11.3.1.a This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. GHCi cannot safely continue in this situation. Exiting now. Sorry. }}} Apparently, ghci has no problem linking packages like array and deepseq twice, but when it comes across loading text another time, we get this duplicate symbol error. Does this make sense? Why does it not detect that text is already linked, like for the other packages? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 16 13:17:37 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Dec 2013 13:17:37 -0000 Subject: [GHC] #960: Lexical call site string In-Reply-To: <057.da5a7918d3a237f53bbf07bfe2771af6@haskell.org> References: <057.da5a7918d3a237f53bbf07bfe2771af6@haskell.org> Message-ID: <072.65be894008708054ed0327216c5292ea@haskell.org> #960: Lexical call site string -------------------------------------+------------------------------------ Reporter: paul@? | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: N/A | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by Tarrasch): * cc: miffoljud@? (added) Comment: I think this could be superseded by #3693. Only that it would require compilation with something like `-g`. There's also multiple overhead-full stack trace implementations today. It might be time to close this whenever #3693 closes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 16 16:32:35 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Dec 2013 16:32:35 -0000 Subject: [GHC] #8615: All packages built with GHC / clang are failing Message-ID: <048.e36a39a5d17ec159ef0786deeff58f72@haskell.org> #8615: All packages built with GHC / clang are failing ------------------------------------+------------------------------------- Reporter: sylvestre | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I am trying to rebuild the Debian archive using clang instead of gcc. The biggest source of errors (622 over 2188 [1]) is related to GHC. Clang does not implement the "-u" option [2]. This is causing most (all?) of the "GHC based" packages to fail to build. with: {{{ /usr/lib/ghc/libHSrts.a(RtsStartup.o): In function `hs_exit_': (.text+0x49): undefined reference to `base_GHCziTopHandler_flushStdHandles_closure' }}} Of course, if you think it is not GHC's fault at all or there is no workaround, don't hesitate to close this bug. For example: http://clang.debian.net/logs/2013-07-14/agda_2.3.2.1-1_unstable_clang.log http://clang.debian.net/logs/2013-07-14/happy_1.18.10-2_unstable_clang.log [1] http://clang.debian.net/status.php?version=3.3&key=MISSING_OPTION_U [2] http://llvm.org/bugs/show_bug.cgi?id=18250 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 16 17:43:42 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Dec 2013 17:43:42 -0000 Subject: [GHC] #8615: All packages built with GHC / clang are failing In-Reply-To: <048.e36a39a5d17ec159ef0786deeff58f72@haskell.org> References: <048.e36a39a5d17ec159ef0786deeff58f72@haskell.org> Message-ID: <063.d93b1a5a48fa82694432c6de55b1d182@haskell.org> #8615: All packages built with GHC / clang are failing -------------------------------------+------------------------------------ Reporter: sylvestre | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by carter): * status: new => closed * resolution: => fixed Comment: GHC 7.6 wont build with clang, unless you backport a few patches from the ghc head. ghc 7.7 / HEAD / soon 7.8 should build with clang HEAD (also the bug fix branch of clang 3.3 works too). so while this concern is valid, the fixes are in the more current work on GHC. So i'm going to close it as "fixed" :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 16 19:27:08 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Dec 2013 19:27:08 -0000 Subject: [GHC] #8616: "Internal error" with ScopedTypeVariables and kind variables Message-ID: <047.f65784d6e37be57e3df5d424a2fe4ddd@haskell.org> #8616: "Internal error" with ScopedTypeVariables and kind variables ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When I try to compile the following nonsense with HEAD {{{ {-# LANGUAGE PolyKinds, RankNTypes, ScopedTypeVariables #-} import Data.Proxy import GHC.Exts withSomeSing :: forall (kproxy :: k). Proxy kproxy withSomeSing = undefined :: (Any :: k) }}} I get this {{{ GHC internal error: ?k? is not in scope during type checking, but it passed the renamer tcl_env of environment: [(a4XG, Type variable ?kproxy? = kproxy), (r4MW, Identifier[withSomeSing::forall (k :: BOX) (kproxy :: k). Proxy k kproxy, ])] In the kind ?k? In an expression type signature: (Any :: k) In the expression: undefined :: (Any :: k) }}} The code is very bogus, but so is GHC's response. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 17 06:55:09 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Dec 2013 06:55:09 -0000 Subject: [GHC] #8617: Documentation does not mention '-fno-ignore-asserts' Message-ID: <045.6a5c802c367efde134fc054670a350f7@haskell.org> #8617: Documentation does not mention '-fno-ignore-asserts' ------------------------------------+------------------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The attached patch makes '-fno-ignore-asserts' more prominent in the documentation. The ability to leave assertions enabled in release builds is very useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 17 08:23:17 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Dec 2013 08:23:17 -0000 Subject: [GHC] #8615: All packages built with GHC / clang are failing In-Reply-To: <048.e36a39a5d17ec159ef0786deeff58f72@haskell.org> References: <048.e36a39a5d17ec159ef0786deeff58f72@haskell.org> Message-ID: <063.c5016978ce1f5778f588b0aa7cb283ba@haskell.org> #8615: All packages built with GHC / clang are failing -------------------------------------+------------------------------------ Reporter: sylvestre | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by sylvestre): OK. Thanks :) Any chance you have the list of patches to backport to 7.6 ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 17 11:19:54 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Dec 2013 11:19:54 -0000 Subject: [GHC] #8617: Documentation does not mention '-fno-ignore-asserts' In-Reply-To: <045.6a5c802c367efde134fc054670a350f7@haskell.org> References: <045.6a5c802c367efde134fc054670a350f7@haskell.org> Message-ID: <060.80a0c62436d0456e7cb4d8d68d040caf@haskell.org> #8617: Documentation does not mention '-fno-ignore-asserts' -------------------------------------+------------------------------------ Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"ddd1c8209a69b9ed1cdad2a9b47a7e47bbd4bc96/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ddd1c8209a69b9ed1cdad2a9b47a7e47bbd4bc96" Mention '-fno-ignore-asserts' in documentation. (Closes: #8617) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 17 11:26:40 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Dec 2013 11:26:40 -0000 Subject: [GHC] #8617: Documentation does not mention '-fno-ignore-asserts' In-Reply-To: <045.6a5c802c367efde134fc054670a350f7@haskell.org> References: <045.6a5c802c367efde134fc054670a350f7@haskell.org> Message-ID: <060.f6479a215b667f1490b13bd1339a5e7d@haskell.org> #8617: Documentation does not mention '-fno-ignore-asserts' -------------------------------------+------------------------------------ Reporter: refold | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * status: new => closed * resolution: => fixed Comment: Thanks for your contribution; pushed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 17 16:09:21 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Dec 2013 16:09:21 -0000 Subject: [GHC] #8615: All packages built with GHC / clang are failing In-Reply-To: <048.e36a39a5d17ec159ef0786deeff58f72@haskell.org> References: <048.e36a39a5d17ec159ef0786deeff58f72@haskell.org> Message-ID: <063.a30f4d28b0da13a03b5516911fbfa5d0@haskell.org> #8615: All packages built with GHC / clang are failing -------------------------------------+------------------------------------ Reporter: sylvestre | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): Darin Morrison has some in progress branches on this, though I think he'd LOVE some help finishing the work. https://github.com/darinmorrison/ghc look at the 7.6.3 mavericks and the 7.6.3 mavericks + clang branches -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 17 16:29:53 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Dec 2013 16:29:53 -0000 Subject: [GHC] #8615: All packages built with GHC / clang are failing In-Reply-To: <048.e36a39a5d17ec159ef0786deeff58f72@haskell.org> References: <048.e36a39a5d17ec159ef0786deeff58f72@haskell.org> Message-ID: <063.f972f4d88808a09b4cb0c16384e49179@haskell.org> #8615: All packages built with GHC / clang are failing -------------------------------------+------------------------------------ Reporter: sylvestre | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): @sylvestre, I think Darin's a bit burnt out on it, but if you want to carry the torg to the finish line so that 7.6 + clang / mavericks play nice, that'd be neat. NB:it may be a bit of work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 18 08:53:27 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Dec 2013 08:53:27 -0000 Subject: [GHC] #7452: [GNU gold] ld: error: cannot find [...]/Types__1.o In-Reply-To: <045.e0a31be3fad6f397a63ade6e4c217e60@haskell.org> References: <045.e0a31be3fad6f397a63ade6e4c217e60@haskell.org> Message-ID: <060.981917d1162b8c1f44407ca4f4f66428@haskell.org> #7452: [GNU gold] ld: error: cannot find [...]/Types__1.o ----------------------------------------+---------------------------------- Reporter: mrothe | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Build System | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by gidyn): The gold linker doesn't understand relative paths. This also effects building anything with -split-objs, see https://bugzilla.redhat.com/show_bug.cgi?id=635935 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 19 05:04:50 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Dec 2013 05:04:50 -0000 Subject: [GHC] #8607: Invalid location reported for type constructors In-Reply-To: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> References: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> Message-ID: <059.60b1706802ef2fbb0bcc63d9a1326765@haskell.org> #8607: Invalid location reported for type constructors -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by goldfire): * owner: goldfire => Comment: So, I took a look at this, and it's ugly. The problem is that each `TyClDecl` can give rise to potentially many top-level things. Of these things, only the `TyCon`s are checked for validity, so we really only need location info for `TyCon`s. It's a little painful returning a `[Located TyThing]` when the `Located` bit applies to only one disjunct of `TyThing`. But, I was willing to deal with that. The real problem comes from the fact that one declaration can actually produce many `TyCon`s: a class with associated types. According to the validity checking code -- which checks all `TyCon`s, top-level and not -- we would need these associated type `TyCon`s to have correct locations. Unfortunately, there is no clean way to get good locations for associated types without polluting the code in `tcClassATs` and possibly `ClassATItem`, which is persisted within the `Class` datatype. Very yuck. Is all of this doable? Absolutely, but it would make Simon wish he had just stayed on holiday. So, I propose that, to fix this problem, we store location information ''in the `TyCon`''. This should be easy to get correct and easy to use. It would be cleaner than adding `Located` in various places throughout !TcTyClsDecls. But, it stores location information in a very Core-ish place, and I would rather consult with others before going ahead with this plan. There is precedent: `CoAxBranch`es store locations for similar reasons. But, of course, I was the chief person behind `CoAxBranch`es, and it's a little silly to use my own design decision as precedent. Thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 19 08:05:52 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Dec 2013 08:05:52 -0000 Subject: [GHC] #8618: can't load .so/.DLL Message-ID: <048.2735393b0fb36a2447e9e970e62e9258@haskell.org> #8618: can't load .so/.DLL -----------------------------------+--------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- This happens in a fresh sandbox: {{{ % cabal install uniplate -j Resolving dependencies... Configuring syb-0.4.1... Configuring text-1.0.0.0... Building syb-0.4.1... Building text-1.0.0.0... Installed syb-0.4.1 Installed text-1.0.0.0 Configuring hashable-1.2.1.0... Building hashable-1.2.1.0... Installed hashable-1.2.1.0 Configuring unordered-containers-0.2.3.3... Building unordered-containers-0.2.3.3... Installed unordered-containers-0.2.3.3 Configuring uniplate-1.6.12... Building uniplate-1.6.12... Failed to install uniplate-1.6.12 Last 10 lines of the build log ( /home/feuerbach/.cabal/logs/uniplate-1.6.12.log ): Preprocessing library uniplate-1.6.12... [ 1 of 21] Compiling Data.Generics.Uniplate.Data.Instances ( Data/Generics/Uniplate/Data/Instances.hs, dist/build/Data/Generics/Uniplate/Data/Instances.o ) [ 2 of 21] Compiling Data.Generics.Uniplate.Internal.Utils ( Data/Generics/Uniplate/Internal/Utils.hs, dist/build/Data/Generics/Uniplate/Internal/Utils.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package text-1.0.0.0 ... : can't load .so/.DLL for: libHStext-1.0.0.0.so (libHStext-1.0.0.0.so: cannot open shared object file: No such file or directory) cabal: Error: some packages failed to install: uniplate-1.6.12 failed during the building phase. The exception was: ExitFailure 1 }}} I have shared: False in cabal.config, so it's not surprising that libHStext-1.0.0.0.so is not found. What is surprising is that it's needed. uniplate doesn't use TemplateHaskell, from what I can tell. This is GHC 7.7.20131217. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 19 08:21:20 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Dec 2013 08:21:20 -0000 Subject: [GHC] #8618: can't load .so/.DLL In-Reply-To: <048.2735393b0fb36a2447e9e970e62e9258@haskell.org> References: <048.2735393b0fb36a2447e9e970e62e9258@haskell.org> Message-ID: <063.0288f293c91148393b84c97a8cb583fe@haskell.org> #8618: can't load .so/.DLL ---------------------------------------+----------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by carter): What OS and Arch is this? Why do you have shared disabled? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 19 08:33:50 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Dec 2013 08:33:50 -0000 Subject: [GHC] #8618: can't load .so/.DLL In-Reply-To: <048.2735393b0fb36a2447e9e970e62e9258@haskell.org> References: <048.2735393b0fb36a2447e9e970e62e9258@haskell.org> Message-ID: <063.9aef8edb8788aa34c5fd4be34ffb26c6@haskell.org> #8618: can't load .so/.DLL ---------------------------------------+----------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by Feuerbach): {{{ % uname -a Linux sniper 3.11-2-686-pae #1 SMP Debian 3.11.8-1 (2013-11-13) i686 GNU/Linux }}} "shared: False" is from some older times when ghc actually had problems with dynamic linking. I already switched to "shared: True", but I thought I'd still report the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 19 11:22:21 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Dec 2013 11:22:21 -0000 Subject: [GHC] #8607: Invalid location reported for type constructors In-Reply-To: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> References: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> Message-ID: <059.ceef45298dd60fd8e195a132be4dc6a2@haskell.org> #8607: Invalid location reported for type constructors -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by edsko): So correct me if I'm wrong, but -- `TyCon` contains a `Name`, right? And that `Name` has a `nameSrcSpan`. And that `nameSrcSpan` is what is used for error messages (probably through `setSrcSpan (getSrcSpan thing)` at the start of `checkValidTyCl`?). So `TyCon`s ''already'' have a built-in location, and I guess this was precisely the purpose of Simon's patch. I don't have a problem with the `nameSrcSpan` of a `Name` being set to be the location of the entire type declaration. What ''is'' a problem, however, is that in the AST, that name becomes a `Located Name`, for example as in {{{ data TyClDecl name | -- | @data@ declaration DataDecl { tcdLName :: Located name -- ^ Type constructor ... }}} So `Located Name` has ''two'' `SrcSpan`s; one for the `Located` part, and one for the `Name` part (`nameSrcSpan`). The problem is that Simon's patch changed ''both'' of these `SrcSpan`s to point to the entire span of the type declaration. They are logically different -- one tells you where ''this occurrence'' of the identifier is, the other tells you where the identifier is defined. For IDE purposes we need to know accurate information about the location of this occurrence, even if it's `nameSrcSpan` (def site) points somewhere else. Do I make any sense at all? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 19 18:28:20 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Dec 2013 18:28:20 -0000 Subject: [GHC] #8607: Invalid location reported for type constructors In-Reply-To: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> References: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> Message-ID: <059.b7e4aab6ee5d46fb2592368a67be2d2c@haskell.org> #8607: Invalid location reported for type constructors -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): Yes, I see what you're saying much better now. But, it still doesn't seem to quite correspond with what's going on in Simon's original change. That commit (1745779...) seems to change only the location in the `Located` bit, not the one in the `nameSrcSpan`. Oh, it's all suddenly clear. Simon's commit was overzealous. It turns out that the location stored in the `Located` bit in a `tcdLName` seems to be ignored in the validity checker -- it's only the location in the `nameSrcSpan` that does any work. So, the changes Simon made to !RdrHsSyn were totally unnecessary to correspond to the refactoring in !TcTyClsDecls. The solution is dead easy: I can just revert the changes in !RdrHsSyn and revert the corresponding changes in the testsuite, while keeping the refactoring in !TcTyClsDecls, which was the whole point to begin with. Have to run now, but will do this later today. Thanks for pointing me in this direction! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 20 10:38:27 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Dec 2013 10:38:27 -0000 Subject: [GHC] #7897: MakeTypeRep fingerprints be proper, robust fingerprints In-Reply-To: <046.71438f4eb0adc834d5130a615d3ff9d8@haskell.org> References: <046.71438f4eb0adc834d5130a615d3ff9d8@haskell.org> Message-ID: <061.360945965cfc54948ae2e5d43cad55a4@haskell.org> #7897: MakeTypeRep fingerprints be proper, robust fingerprints -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): I'll point out that the package name contains the version, so in most cases the current scheme is safe. Of course this doesn't help for the main package, but if you're serializing data from a properly packaged library, it's fine. The other problem is that !TypeReps will be currently distinguished when it would be safe to equate them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 20 13:22:17 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Dec 2013 13:22:17 -0000 Subject: [GHC] #8619: Support anonymous string literals in C-- (OR) give better ASSERT failure messages in C-- Message-ID: <045.bc17add61e78f8a5d6d2200d15a0dca2@haskell.org> #8619: Support anonymous string literals in C-- (OR) give better ASSERT failure messages in C-- ------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- So if I say "foobar" in C--, it turns into: {{{ section "rodata" { fresh_name : bits8[] "foobar\0"; } }}} This would let us fix the ASSERT macro in Cmm.h to also get the filename. Requires parser changes. Alternatively, we can redefine the ASSERT macro per C-- file to have a hardcoded filename with some preprocessor trickery. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 20 17:09:20 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Dec 2013 17:09:20 -0000 Subject: [GHC] #8619: Support anonymous string literals in C-- (OR) give better ASSERT failure messages in C-- In-Reply-To: <045.bc17add61e78f8a5d6d2200d15a0dca2@haskell.org> References: <045.bc17add61e78f8a5d6d2200d15a0dca2@haskell.org> Message-ID: <060.6da0f48d64030e181b5639f5832761d4@haskell.org> #8619: Support anonymous string literals in C-- (OR) give better ASSERT failure messages in C-- -------------------------------------+------------------------------------ Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): This would also pave the way to supporting static data structures more generally right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 20 19:32:26 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Dec 2013 19:32:26 -0000 Subject: [GHC] #8619: Support anonymous string literals in C-- (OR) give better ASSERT failure messages in C-- In-Reply-To: <045.bc17add61e78f8a5d6d2200d15a0dca2@haskell.org> References: <045.bc17add61e78f8a5d6d2200d15a0dca2@haskell.org> Message-ID: <060.6669cee2687a29d2d23eb37c0dbc3b52@haskell.org> #8619: Support anonymous string literals in C-- (OR) give better ASSERT failure messages in C-- -------------------------------------+------------------------------------ Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ezyang): No, you can already specify data to be placed in a read-only data section; the only reason really to want string literals is convenience and macro situations like ASSERT. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 21 17:00:45 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Dec 2013 17:00:45 -0000 Subject: [GHC] #8620: build of head on Mac 10.9 with xcode 5 fails with Message-ID: <045.6b8d5402d68421f521d87e4314812585@haskell.org> #8620: build of head on Mac 10.9 with xcode 5 fails with ----------------------------------+--------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- make -j3 fails with Configuring ghc-bin-7.7.20131217... Warning: 'data-dir: ..' is a relative path outside of the source tree. This will not work when generating a tarball with 'sdist'. ghc.mk:100: *** Make has restarted itself 2 times; is there a makefile bug? See http://ghc.haskell.org/trac/ghc/wiki/Building/Troubleshooting#Makehasrestarteditself3timesisthereamakefilebug for details. Stop. make: *** [all] Error 2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 21 18:25:37 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Dec 2013 18:25:37 -0000 Subject: [GHC] #8585: Loopification should omit stack check In-Reply-To: <048.357f98b67b6c2b39906af5ad1988d2df@haskell.org> References: <048.357f98b67b6c2b39906af5ad1988d2df@haskell.org> Message-ID: <063.7143e9e9352560f3de82b22b37372fbf@haskell.org> #8585: Loopification should omit stack check --------------------------------------------+------------------------------ Reporter: jstolarek | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by jstolarek): * owner: => jstolarek Comment: Patrick, your patch validates successfully. I now see that it indeed places the loop header in the right place. What I don't fully understand in the code that generates the loop header: {{{ self_loop_info <- getSelfLoop case self_loop_info of Just (_, loop_header_id, _) | checkYield && isJust mb_stk_hwm -> emitLabel loop_header_id _otherwise -> return () }}} is the additional condition `checkYield && isJust mb_stk_hwm`. My understanding is that currently heap checks can be placed not only at the entry point to a function but also in the case alternatives, thunk entry points and few other places (according to Note [Heap checks]). We however want to emit loop header only before the heap check made when entering a function and I guess that `checkYield && isJust mb_stk_hwm` condition accomplishes just that. Is that correct? I wasn't able yet to fully convince myself that this always works. I'm not committing the fix until I am certain that it will always work the way we intend it to. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 21 18:56:02 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Dec 2013 18:56:02 -0000 Subject: [GHC] #8621: Pull request for inclusion in `unix' module of fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2) Message-ID: <050.ccaf00573c35157f252c17db26bcc258@haskell.org> #8621: Pull request for inclusion in `unix' module of fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2) -------------------------------------------+------------------------------- Reporter: jimenezrick | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/unix | Version: 7.6.3 Keywords: | Operating System: POSIX Architecture: Unknown/Multiple | Type of failure: Difficulty: Easy (less than 1 hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: -------------------------------------------+------------------------------- Discussion in the mailing list (I fixed both commented silly issues): http://www.haskell.org/pipermail/libraries/2013-December/021756.html Please review this pull request: https://github.com/jimenezrick/unix/compare/master...file-utils.patch If you find interesting this patch, then: git pull https://github.com/jimenezrick/unix.git file-utils -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 21 22:27:42 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Dec 2013 22:27:42 -0000 Subject: [GHC] #8622: Importing modules in .ghci file doesn't not work Message-ID: <045.da51299b2472d1ff8f4ee8cce5f9a2e8@haskell.org> #8622: Importing modules in .ghci file doesn't not work ----------------------------------+--------------------------------- Reporter: m4dc4p | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- When attempting to import a module in the .ghci file, GHCi does not seem to use the search path. Define a module names "Macros.hs": {{{ module Macros where hello :: String -> IO String hello msg = return ("putStrLn " ++ show msg) }}} Now, in the same directory, create a .ghci file: {{{ import Macros :def hello hello }}} Run GHCi from that same directory, and you get an error: {{{ $ ghci GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. : Could not find module `Macros' It is not a module in the current program, or in any known package. :1:25: Not in scope: `hello' }}} It seems that GHCi should be able to find "Macros.hs", compile it, and all me to use it in defining macros. Adding the current directory (relative or absolute) to the search path (using -i) doesn't help. Why do I want to do this? I want to define GHCi macros in a separate module (that is not related to my program) and import them, rather than defining them directly in the .ghci file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 22 11:00:54 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Dec 2013 11:00:54 -0000 Subject: [GHC] #8622: Importing modules in .ghci file doesn't not work In-Reply-To: <045.da51299b2472d1ff8f4ee8cce5f9a2e8@haskell.org> References: <045.da51299b2472d1ff8f4ee8cce5f9a2e8@haskell.org> Message-ID: <060.6f42d193fda52061a3b1818ce54137d8@haskell.org> #8622: Importing modules in .ghci file doesn't not work ---------------------------------+---------------------------------- Reporter: m4dc4p | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+---------------------------------- Comment (by nomeata): Independent of this possible bug, note that in GHCi you can use symbols without importing them, by using a fully qualified name `Macros.hello`. This works best if you create a Cabal package with Macros and install it. See http://darcs.nomeata.de/ghc-heap-view/ghci for examples. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 22 11:10:22 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Dec 2013 11:10:22 -0000 Subject: [GHC] #8623: Strange slowness when using async library with FFI callbacks Message-ID: <050.b698b67eedde827d2c2feb4d7fb38092@haskell.org> #8623: Strange slowness when using async library with FFI callbacks ------------------------------+-------------------------------------------- Reporter: | Owner: simonmar JohnWiegley | Status: new Type: bug | Milestone: 7.8.1 Priority: normal | Version: 7.6.3 Component: Runtime | Operating System: MacOS X System | Type of failure: Runtime performance bug Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- I've attached a Haskell and a C file, when compiled as such: ghc -DSPEED_BUG=0 -threaded -O2 -main-is SpeedTest SpeedTest.hs SpeedTestC.c You should find that with 7.4.2, 7.6.3 or a recent build of 7.8, building with SPEED_BUG=0 produces an executable that takes more than a second to run, while building with SPEED_BUG=1 runs very quickly. I've also attached the Core for both scenarios. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 22 11:26:37 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Dec 2013 11:26:37 -0000 Subject: [GHC] #8623: Strange slowness when using async library with FFI callbacks In-Reply-To: <050.b698b67eedde827d2c2feb4d7fb38092@haskell.org> References: <050.b698b67eedde827d2c2feb4d7fb38092@haskell.org> Message-ID: <065.b37373c596cc477018aeb3fea790fea4@haskell.org> #8623: Strange slowness when using async library with FFI callbacks --------------------------------------------+------------------------------ Reporter: JohnWiegley | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by hvr): fwiw, I suspect some kind of lock contention issue, as the runtime goes down as soon as there's some delay involved (such as `putStr` or even using `threadDelay` which causes the thread to yield) as well as using more than one HEC via `+RTS -N2` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 22 11:27:59 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Dec 2013 11:27:59 -0000 Subject: [GHC] #8623: Strange slowness when using async library with FFI callbacks In-Reply-To: <050.b698b67eedde827d2c2feb4d7fb38092@haskell.org> References: <050.b698b67eedde827d2c2feb4d7fb38092@haskell.org> Message-ID: <065.60cf18a3ac22eaae8db35476c5ba490e@haskell.org> #8623: Strange slowness when using async library with FFI callbacks --------------------------------------------+------------------------------ Reporter: JohnWiegley | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Description changed by hvr: Old description: > I've attached a Haskell and a C file, when compiled as such: > > ghc -DSPEED_BUG=0 -threaded -O2 -main-is SpeedTest SpeedTest.hs > SpeedTestC.c > > You should find that with 7.4.2, 7.6.3 or a recent build of 7.8, building > with SPEED_BUG=0 produces an executable that takes more than a second to > run, while building with SPEED_BUG=1 runs very quickly. I've also > attached the Core for both scenarios. New description: I've attached a Haskell and a C file, when compiled as such: {{{ ghc -DSPEED_BUG=0 -threaded -O2 -main-is SpeedTest SpeedTest.hs SpeedTestC.c }}} You should find that with 7.4.2, 7.6.3 or a recent build of 7.8, building with `SPEED_BUG=0` produces an executable that takes more than a second to run, while building with `SPEED_BUG=1` runs very quickly. I've also attached the Core for both scenarios. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 22 11:28:23 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Dec 2013 11:28:23 -0000 Subject: [GHC] #8623: Strange slowness when using async library with FFI callbacks In-Reply-To: <050.b698b67eedde827d2c2feb4d7fb38092@haskell.org> References: <050.b698b67eedde827d2c2feb4d7fb38092@haskell.org> Message-ID: <065.70941bd2e6d7473203ee5e38221c22f8@haskell.org> #8623: Strange slowness when using async library with FFI callbacks --------------------------------------------+------------------------------ Reporter: JohnWiegley | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by JohnWiegley): But {{{Control.Concurrent.yield}}} does not help, which I would have thought would also cause the thread to yield. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 22 11:38:08 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Dec 2013 11:38:08 -0000 Subject: [GHC] #8623: Strange slowness when using async library with FFI callbacks In-Reply-To: <050.b698b67eedde827d2c2feb4d7fb38092@haskell.org> References: <050.b698b67eedde827d2c2feb4d7fb38092@haskell.org> Message-ID: <065.ab1d6201112703127651dbc2b1db6e86@haskell.org> #8623: Strange slowness when using async library with FFI callbacks --------------------------------------------+------------------------------ Reporter: JohnWiegley | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by JohnWiegley): I tried using just `forkIO` and `MVar`, but it does not exhibit the problem: {{{ main = do let test = mk'speed_test_cb (return ()) >>= speed_test test m <- newEmptyMVar _ <- forkIO $ test >> putMVar m () takeMVar m }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 23 02:01:18 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Dec 2013 02:01:18 -0000 Subject: [GHC] #8624: -ddump-splices-file Message-ID: <048.f5eead94409241401357105f8bb65a4f@haskell.org> #8624: -ddump-splices-file ------------------------------------+------------------------------------- Reporter: GregWeber | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I am proposing an additional feature, `-ddump-splices-file` that generates a corresponding `.hs.th` file for every `.hs` file that uses Template Haskell. `-ddump-splices` is an invaluable but a frustrating way to look at generated Haskell code. If TH generation were some kind of error message, the current output would make sense. However, TH is generating code that we rely on and would be easier to comprehend if we could see it in a way the most similar to our existing Haskell code. There is a valid complaint that when TH defines something you can't just grep for it, you have to know what TH is defining by reading documentation and imagining something that isn't in front of you. If you have a file `Foo.hs` `-ddump-splices-file` will generate `Foo.hs.th`. Then whenever someone greps after buliding they will find the declaration. If you check these files in they can grep even before building. Similarly, an IDE can show these files as the source of a declaration. Also, if the TH generation changes in some way when a TH function changes, that will be visible. This seems like a relatively easy feature to add. Any pointers on where to get started? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 23 11:31:31 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Dec 2013 11:31:31 -0000 Subject: [GHC] #8625: GHCi does not support some TH elements, while those elemenst are working in hs files Message-ID: <046.0f31ee1e49a02b8e04444700e0dded78@haskell.org> #8625: GHCi does not support some TH elements, while those elemenst are working in hs files ------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Hello. Below is a code, which works when using runhaskell, but does not work in GHCi. In GHCi we get following error: runQ [d| instance ( y ~ (t->t) ) => Member Vector y where member v = test |] :19:6: Exotic predicate type not (yet) handled by Template Haskell y ~ (t -> t) code: {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TemplateHaskell #-} module Main where import Language.Haskell.TH class a ~ b => HEq a b test :: a -> a test x = x data Vector class Member a b where member :: a -> b main :: IO () main = print =<< runQ [d| instance y ~ (t->t) => Member Vector y where member v = test |] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 23 11:38:29 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Dec 2013 11:38:29 -0000 Subject: [GHC] #8625: GHCi does not support some TH elements, while those elemenst are working in hs files In-Reply-To: <046.0f31ee1e49a02b8e04444700e0dded78@haskell.org> References: <046.0f31ee1e49a02b8e04444700e0dded78@haskell.org> Message-ID: <061.80be28175a79bb2c89446205458f1810@haskell.org> #8625: GHCi does not support some TH elements, while those elemenst are working in hs files -------------------------------------+------------------------------------ Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by danilo2): We discovered now, that the error not always appears in GHCi session. It appears if we use following commands: :set -XTypeFamilies :set -XTemplateHaskell :set -XUndecidableInstances :set -XFlexibleInstances :set -XMultiParamTypeClasses :m + Language.Haskell.TH data Vector = Vector let test x = x class Member a f where member :: a -> f runQ [d| instance ( y ~ (t->t) ) => Member Vector y where member v = test |] :19:6: Exotic predicate type not (yet) handled by Template Haskell y ~ (t -> t) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 23 15:57:53 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Dec 2013 15:57:53 -0000 Subject: [GHC] #8624: -ddump-splices-file In-Reply-To: <048.f5eead94409241401357105f8bb65a4f@haskell.org> References: <048.f5eead94409241401357105f8bb65a4f@haskell.org> Message-ID: <063.f3e73ffb1d09a3ba97953cf62064359c@haskell.org> #8624: -ddump-splices-file -------------------------------------+------------------------------------ Reporter: GregWeber | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): I think the first step would be to write up a concrete proposal for the new feature on a wiki page. A few questions I have that would need to be answered: * If the source file is a .lhs file, is the output .lhs.th? * Can a user alter the extension? * Can a user alter the directory where this file is created? Then, for implementing it, I would start by looking at !DynFlags and then poking around to see how -ddump-splices works. I imagine it wouldn't be difficult just to redirect the -ddump-splices output to a file. Caveat: I haven't done anything quite like this to GHC, so my suggestions may be wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 23 16:09:48 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Dec 2013 16:09:48 -0000 Subject: [GHC] #8624: -ddump-splices-file In-Reply-To: <048.f5eead94409241401357105f8bb65a4f@haskell.org> References: <048.f5eead94409241401357105f8bb65a4f@haskell.org> Message-ID: <063.c0f357f415c9f746a3aab739202c9988@haskell.org> #8624: -ddump-splices-file -------------------------------------+------------------------------------ Reporter: GregWeber | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by GregWeber): Thanks for the feedback and the pointers. 1) yes. I thought appending `.th` would be good because it is tab- completion friendly, but it also appears to be friendly to different haskell extensions. 2) no, we would want to see feedback from users that this is necessary. If `.th` is too overloaded we could just make it bigger. One more character, such as `.ths` might help. Although the extension could easily conflict with someone's computer-wide filesystem, it is unlikely to conflict in a directory with Haskell code. 3) no, we would want to see feedback from users that this is necessary -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 23 17:39:36 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Dec 2013 17:39:36 -0000 Subject: [GHC] #8624: -ddump-splices-file In-Reply-To: <048.f5eead94409241401357105f8bb65a4f@haskell.org> References: <048.f5eead94409241401357105f8bb65a4f@haskell.org> Message-ID: <063.fbc7e534ab2d01d686705afe26e4d8bb@haskell.org> #8624: -ddump-splices-file -------------------------------------+------------------------------------ Reporter: GregWeber | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Yay bikeshedding: I?d recommend `Foo.th`, just like the `.imports` file that `-ddump- minimal-imports` generates. That is probably a feature you?d want to look at, as it is somewhat similar to what you want. Also, it would be useful if the `.th` file contains precise code locations of the origin of the splices. This would allow the tools that replace TH splices by their output in the original file to use the `.th` file conveniently. Bonus points (well, different and more complicated feature actually, so ignore this for now): Enable a mode where `GHC` will read the `.th` file and use that instead of actually running Template Haskell. Distributing the `.th` files will then allow building packages on architectures where Template Haskell is not available. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 23 18:24:59 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Dec 2013 18:24:59 -0000 Subject: [GHC] #8622: Importing modules in .ghci file doesn't work (was: Importing modules in .ghci file doesn't not work) In-Reply-To: <045.da51299b2472d1ff8f4ee8cce5f9a2e8@haskell.org> References: <045.da51299b2472d1ff8f4ee8cce5f9a2e8@haskell.org> Message-ID: <060.749b522860614b504bd44f2d6a1d49ad@haskell.org> #8622: Importing modules in .ghci file doesn't work ---------------------------------+---------------------------------- Reporter: m4dc4p | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+---------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 23 18:25:47 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Dec 2013 18:25:47 -0000 Subject: [GHC] #8622: Importing modules in .ghci file doesn't work In-Reply-To: <045.da51299b2472d1ff8f4ee8cce5f9a2e8@haskell.org> References: <045.da51299b2472d1ff8f4ee8cce5f9a2e8@haskell.org> Message-ID: <060.c8ca25c4c20f15e5c348fb311381c8c7@haskell.org> #8622: Importing modules in .ghci file doesn't work ---------------------------------+---------------------------------- Reporter: m4dc4p | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+---------------------------------- Comment (by m4dc4p): Replying to [comment:1 nomeata]: > This works best if you create a Cabal package with Macros and install it. See http://darcs.nomeata.de/ghc-heap-view/ghci for examples. That seems to be the best workaround, but it is a bit of a pain. Thanks for the example! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 23 18:39:10 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Dec 2013 18:39:10 -0000 Subject: [GHC] #8624: -ddump-splices-file In-Reply-To: <048.f5eead94409241401357105f8bb65a4f@haskell.org> References: <048.f5eead94409241401357105f8bb65a4f@haskell.org> Message-ID: <063.04f9ca6cea053075a89f32fb2b90375f@haskell.org> #8624: -ddump-splices-file -------------------------------------+------------------------------------ Reporter: GregWeber | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by GregWeber): Thanks for the pointer to `-ddump-minimal-imports` Adding location information is a great idea, and if is easy to put the locations in a comment I will do that. However, you might need to get involved with this to add in the features you want. Build-caching is a very interesting feature, but I think it will require GHC/cabal build experts and otherwise a lot more input to think about and implement correctly, so I will leave that for another ticket. The problem with `Foo.th` is that now tab completion of the filename stops at `Foo.`. Whereas with `Foo.hs.th` tab completion first stops at `Foo.hs`, which is what you want most of the time. Also, `.hs.th` together makes for a more unique file extension. If this feature is extended to build caching there will probably be a desire to change how the extensions work. This will actually be a good thing since it will avoid the need to think about backwards compatible files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 23 19:15:43 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Dec 2013 19:15:43 -0000 Subject: [GHC] #8624: -ddump-splices-file In-Reply-To: <048.f5eead94409241401357105f8bb65a4f@haskell.org> References: <048.f5eead94409241401357105f8bb65a4f@haskell.org> Message-ID: <063.87e328f77aeaf3736ac1467b1502bb7b@haskell.org> #8624: -ddump-splices-file -------------------------------------+------------------------------------ Reporter: GregWeber | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Replying to [comment:4 GregWeber]: > Adding location information is a great idea, and if is easy to put the locations in a comment I will do that. However, you might need to get involved with this to add in the features you want. Build-caching is a very interesting feature, but I think it will require GHC/cabal build experts and otherwise a lot more input to think about and implement correctly, so I will leave that for another ticket. Yes, that was just brianstorming... :-) > The problem with `Foo.th` is that now tab completion of the filename stops at `Foo.`. Whereas with `Foo.hs.th` tab completion first stops at `Foo.hs`, which is what you want most of the time. Maybe its different with different workflows, but I, and probably lots of developers, usually happen to have `.hi` and `.o` files around that prevent the correct completion anyways. So unless you change that to `.hs.hi` and `.hs.o` as well, for the sake of consistency, `.th` is what follows the principle of least surprise. (But note that this is bikeshedding, do not let such a discussion discourage you from implementing the feature in the first place.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 23 20:03:45 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Dec 2013 20:03:45 -0000 Subject: [GHC] #8624: -ddump-splices-file In-Reply-To: <048.f5eead94409241401357105f8bb65a4f@haskell.org> References: <048.f5eead94409241401357105f8bb65a4f@haskell.org> Message-ID: <063.b787ddfec76ba0c8a7be038d67ac2619@haskell.org> #8624: -ddump-splices-file -------------------------------------+------------------------------------ Reporter: GregWeber | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by GregWeber): If you use cabal there shouldn't be `.hi` and `.o` files lying around. If they are around, they should be gitignored. Tab completion can use `.gitignore` at least to favor `.hs` files. I know that doesn't happen by default in most editors though, but I think most of the community is using cabal or some other build system that they could setup to have a dist folder. `.th` files should not end up in `dist/`. Some people might want to gitignore them, but I think if you go to the effort of turning them on you want to check them in. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 23 20:11:48 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Dec 2013 20:11:48 -0000 Subject: [GHC] #8624: -ddump-splices-file In-Reply-To: <048.f5eead94409241401357105f8bb65a4f@haskell.org> References: <048.f5eead94409241401357105f8bb65a4f@haskell.org> Message-ID: <063.4fbaec67681aa5c60b5c877c810005d9@haskell.org> #8624: -ddump-splices-file -------------------------------------+------------------------------------ Reporter: GregWeber | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Besides Cabal, I often use `ghc --make` and `ghci`, both of which leave `.hi` files around next to `.hs`... but this is getting off topic, so I?ll shut up :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 23 20:22:21 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Dec 2013 20:22:21 -0000 Subject: [GHC] #8626: Bad magic. Expected: feedfacf, got: feedface Message-ID: <044.81de4f3ab57a9e527b78bf9c28e8e7c1@haskell.org> #8626: Bad magic. Expected: feedfacf, got: feedface ----------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------------- Loading package base-unicode-symbols-0.2.2.4 ... : /Users/paulo/Library/Haskell/ghc-7.6.3/lib/base-unicode- symbols-0.2.2.4/lib/HSbase-unicode-symbols-0.2.2.4.o: Bad magic. Expected: feedfacf, got: feedface. ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-apple-darwin): loadObj "/Users/paulo/Library/Haskell/ghc-7.6.3/lib/base-unicode- symbols-0.2.2.4/lib/HSbase-unicode-symbols-0.2.2.4.o": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 23 20:23:55 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Dec 2013 20:23:55 -0000 Subject: [GHC] #8624: -ddump-splices-file In-Reply-To: <048.f5eead94409241401357105f8bb65a4f@haskell.org> References: <048.f5eead94409241401357105f8bb65a4f@haskell.org> Message-ID: <063.f2a695bc61ca57375346c19c1b660cd7@haskell.org> #8624: -ddump-splices-file -------------------------------------+------------------------------------ Reporter: GregWeber | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by GregWeber): Thanks for the feedback. What I am suggesting is better for my workflow, but I am not opposed to changing it if needed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 24 00:44:31 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Dec 2013 00:44:31 -0000 Subject: [GHC] #8627: mallocForeignPtrBytes documentation unobvious regarding memory alignment Message-ID: <051.3280a80c672c79dc5007718f42008b81@haskell.org> #8627: mallocForeignPtrBytes documentation unobvious regarding memory alignment ------------------------------------+------------------------------------- Reporter: schernichkin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- According to the current documentation: mallocForeignPtr - is equivalent to do { p <- malloc; newForeignPtr finalizerFree p }. It's ok since we can read that the "block of memory is sufficiently aligned" if the mallocBytes function descriprion and newAlignedPinnedByteArray in the function implementation. mallocForeignPtrBytes - "similar to mallocForeignPtr" but will it alloc aligned memory? Internally it uses newPinnedByteArray which implies memory will not be aligned, but does it really makes any sense? Plz correct documentation to make it more obvious. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 24 05:11:44 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Dec 2013 05:11:44 -0000 Subject: [GHC] #8623: Strange slowness when using async library with FFI callbacks In-Reply-To: <050.b698b67eedde827d2c2feb4d7fb38092@haskell.org> References: <050.b698b67eedde827d2c2feb4d7fb38092@haskell.org> Message-ID: <065.42c007e9eb39791c30b41d0e7ee9625c@haskell.org> #8623: Strange slowness when using async library with FFI callbacks --------------------------------------------+------------------------------ Reporter: JohnWiegley | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by carter): doe the problem go away if the program is compiled in GHC HEAD using {{{ -fno-omit-yields}}} ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 24 08:00:46 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Dec 2013 08:00:46 -0000 Subject: [GHC] #8624: -ddump-splices-file In-Reply-To: <048.f5eead94409241401357105f8bb65a4f@haskell.org> References: <048.f5eead94409241401357105f8bb65a4f@haskell.org> Message-ID: <063.6f582bb5b1f0a7d8529127af174126f7@haskell.org> #8624: -ddump-splices-file -------------------------------------+------------------------------------ Reporter: GregWeber | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by spl): * cc: sean.leather@? (added) Comment: I think I'm at least partly to blame for Greg's proposal, so naturally, I agree with the idea. I just wanted to add a piece of evidence for why I would prefer `Foo.th.hs` over `Foo.hs.th` or `Foo.th`: it allows tools/scripts to find the file when searching for `*.hs`. Of course, tools/scripts can be configured, so this can be worked around. But I find this issue slightly more influential than the tab-completion issue -- I'm accustomed to not having tab completion of the extension. Whatever the decision, I'd be happy to have this feature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 24 21:49:19 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Dec 2013 21:49:19 -0000 Subject: [GHC] #8628: dynCompileExpr breaks repeated runDecls of the same name Message-ID: <049.09ea66098fe70379109ad292dc66392d@haskell.org> #8628: dynCompileExpr breaks repeated runDecls of the same name ------------------------------------+------------------------------------- Reporter: agibiansky | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Using `dynCompileExpr` with `runDecls` from `InteractiveEval` seems to be incredibly problematic when evaluating declarations for the same name. For instance, consider the following code: {{{ runDecls "data X = Y Int" gtry $ runStmt "print (Y 3)" RunToCompletion :: GhcMonad m => m (Either SomeException RunResult) runDecls "data X = Y Int deriving Show" runStmt "print (Y 8)" RunToCompletion }}} As expected, this prints `Y 8` once (the first one fails because `X` is not an instance of `Show`). However, if we insert an arbitrary `dynCompileExpr`, things begin to break: {{{ runDecls "data X = Y Int" gtry $ runStmt "print (Y 3)" RunToCompletion :: GhcMonad m => m (Either SomeException RunResult) runDecls "data X = Y Int deriving Show" _ <- dynCompileExpr "'x'" runStmt "print (Y 8)" RunToCompletion }}} We then get: {{{ No instance for (GHC.Show.Show :Interactive.X) arising from a use of `System.IO.print' Possible fix: add an instance declaration for (GHC.Show.Show :Interactive.X) }}} Which is clearly incorrect - we haven't done anything to change the data declaration. I'm not sure what's going on, but I've tried to investigate into the source of `dynCompileExpr`. It loads `Data.Dynamic` via a `setContext` and then unloads it, and that may be the issue. If we do the following (very similar to the `dynCompileExpr` source), things work fine: {{{ runDecls "data X = Y Int" gtry $ runStmt "print (Y 3)" RunToCompletion :: GhcMonad m => m (Either SomeException RunResult) runDecls "data X = Y Int deriving Show" let stmt = "let __expr = 'x'" Just (ids, hval, fixenv) <- withSession $ \hsc_env -> liftIO $ hscStmt hsc_env stmt vals <- liftIO (unsafeCoerce hval :: IO [Char]) liftIO $ print vals -- thish prints "x", as expected runStmt "print (Y 8)" RunToCompletion }}} I have not tested with GHC API other than 7.6.3, and could not find a bug that was similar to this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 24 23:17:28 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Dec 2013 23:17:28 -0000 Subject: [GHC] #5412: dataTypeConstrs gives unhelpful error message In-Reply-To: <051.725025e2f5a74cbcdbc139f819da79d1@haskell.org> References: <051.725025e2f5a74cbcdbc139f819da79d1@haskell.org> Message-ID: <066.8bdca03512b77cdf71893434ed976c6d@haskell.org> #5412: dataTypeConstrs gives unhelpful error message -------------------------------------+------------------------------------ Reporter: NeilMitchell | Owner: klangner Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: libraries/base | Version: 7.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by klangner): * owner: => klangner * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 25 03:23:49 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Dec 2013 03:23:49 -0000 Subject: [GHC] #8623: Strange slowness when using async library with FFI callbacks In-Reply-To: <050.b698b67eedde827d2c2feb4d7fb38092@haskell.org> References: <050.b698b67eedde827d2c2feb4d7fb38092@haskell.org> Message-ID: <065.dee13e646943c1591b00587e0f553c96@haskell.org> #8623: Strange slowness when using async library with FFI callbacks --------------------------------------------+------------------------------ Reporter: JohnWiegley | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by JohnWiegley): No, it makes no difference. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 25 11:04:15 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Dec 2013 11:04:15 -0000 Subject: [GHC] #5412: dataTypeConstrs gives unhelpful error message In-Reply-To: <051.725025e2f5a74cbcdbc139f819da79d1@haskell.org> References: <051.725025e2f5a74cbcdbc139f819da79d1@haskell.org> Message-ID: <066.3cdf30d98dec91ef1d64e5a0b422dfa1@haskell.org> #5412: dataTypeConstrs gives unhelpful error message -------------------------------------+------------------------------------ Reporter: NeilMitchell | Owner: klangner Type: bug | Status: patch Priority: normal | Milestone: 7.6.2 Component: libraries/base | Version: 7.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by klangner): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 25 15:34:04 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Dec 2013 15:34:04 -0000 Subject: [GHC] #8629: Option 'split-objs' being ignored when trying to reduce object code size in iOS cross-compilation Message-ID: <051.7f175708aaf58854c5eeaa60c17f6275@haskell.org> #8629: Option 'split-objs' being ignored when trying to reduce object code size in iOS cross-compilation ------------------------------------+--------------------------------- Reporter: f1rstmistake | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: ios | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- I have been trying to statically link Pandoc packages to iOS application following the guide in https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS and it's great so far! I have finally successfully use Pandoc library in iOS app, but the binary size is very big! 1. More than 50MB when using Pandoc library. 2. Around 5MB for simple haskell code. I try to add ?split-objs: True? in .cabal/config file, but when running cabal I got this message: {{{ Preprocessing library pandoc-1.12.2.1... unused terminals: 1 on the commandline: Warning: ignoring -fsplit-objs }}} And if I ignore that, at the end of build, I get another error message that stop the build. {{{ cabal: dist-i386/build/Text/Pandoc_o_split: does not exist }}} I try with another package and got similar error message. It seems that split-objs not only being ignored by cross-compilation ghc, but will also fail the build. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 25 17:36:30 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Dec 2013 17:36:30 -0000 Subject: [GHC] #5412: dataTypeConstrs gives unhelpful error message In-Reply-To: <051.725025e2f5a74cbcdbc139f819da79d1@haskell.org> References: <051.725025e2f5a74cbcdbc139f819da79d1@haskell.org> Message-ID: <066.cf47009a02699595dfeb21e5e1e84f25@haskell.org> #5412: dataTypeConstrs gives unhelpful error message -------------------------------------+------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: libraries/base | Version: 7.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * owner: klangner => * status: patch => new Comment: Dear Krzysztof, thanks for the patch. Note that SPJ made a more elaborate proposal in the ticket, namely printing the name of the type with the error message. Do you think you can update your ticket to print a message similar to what Simon proposed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 25 17:36:39 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Dec 2013 17:36:39 -0000 Subject: [GHC] #5412: dataTypeConstrs gives unhelpful error message In-Reply-To: <051.725025e2f5a74cbcdbc139f819da79d1@haskell.org> References: <051.725025e2f5a74cbcdbc139f819da79d1@haskell.org> Message-ID: <066.770f8d210fbd83e9fb214bddb6cb7408@haskell.org> #5412: dataTypeConstrs gives unhelpful error message -------------------------------------+------------------------------------ Reporter: NeilMitchell | Owner: klangner Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: libraries/base | Version: 7.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * owner: => klangner -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 25 20:18:06 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Dec 2013 20:18:06 -0000 Subject: [GHC] #5412: dataTypeConstrs gives unhelpful error message In-Reply-To: <051.725025e2f5a74cbcdbc139f819da79d1@haskell.org> References: <051.725025e2f5a74cbcdbc139f819da79d1@haskell.org> Message-ID: <066.b07a74be21a7739d2285ec28299b7b5d@haskell.org> #5412: dataTypeConstrs gives unhelpful error message -------------------------------------+------------------------------------ Reporter: NeilMitchell | Owner: klangner Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: libraries/base | Version: 7.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by klangner): I can try :-) I can create the following message: ''Data.Data.dataTypeConstrs is not supported for Prelude.Int, as it is not an algebraic data type'' As you can see there is **Prelude.Int** not **Int**. This name is returned by **dataTypeName**. I don't know how to get the name without Prelude prefix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 25 20:21:46 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Dec 2013 20:21:46 -0000 Subject: [GHC] #5412: dataTypeConstrs gives unhelpful error message In-Reply-To: <051.725025e2f5a74cbcdbc139f819da79d1@haskell.org> References: <051.725025e2f5a74cbcdbc139f819da79d1@haskell.org> Message-ID: <066.fe1dc3e86cec41d323f1905d51d593a1@haskell.org> #5412: dataTypeConstrs gives unhelpful error message -------------------------------------+------------------------------------ Reporter: NeilMitchell | Owner: klangner Type: bug | Status: patch Priority: normal | Milestone: 7.6.2 Component: libraries/base | Version: 7.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by klangner): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 25 22:23:57 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Dec 2013 22:23:57 -0000 Subject: [GHC] #5412: dataTypeConstrs gives unhelpful error message In-Reply-To: <051.725025e2f5a74cbcdbc139f819da79d1@haskell.org> References: <051.725025e2f5a74cbcdbc139f819da79d1@haskell.org> Message-ID: <066.18708887041b558a431711f4cafa3e85@haskell.org> #5412: dataTypeConstrs gives unhelpful error message -------------------------------------+------------------------------------ Reporter: NeilMitchell | Owner: nomeata Type: bug | Status: patch Priority: normal | Milestone: 7.6.2 Component: libraries/base | Version: 7.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * owner: klangner => nomeata Comment: I just checked the API as well, and there does not seem to exist a clean way of getting the unqualified name. But as this is just an error message, I think it?s fine. I?ll validate and push. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 25 22:27:28 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Dec 2013 22:27:28 -0000 Subject: [GHC] #5412: dataTypeConstrs gives unhelpful error message In-Reply-To: <051.725025e2f5a74cbcdbc139f819da79d1@haskell.org> References: <051.725025e2f5a74cbcdbc139f819da79d1@haskell.org> Message-ID: <066.656db643a25e3f3d89ce05c4df244c79@haskell.org> #5412: dataTypeConstrs gives unhelpful error message -------------------------------------+------------------------------------ Reporter: NeilMitchell | Owner: klangner Type: bug | Status: patch Priority: normal | Milestone: 7.6.2 Component: libraries/base | Version: 7.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * owner: nomeata => klangner Comment: Wait: The second patch only modifies `dataTypeConstrs` while the first patch changes the error message of several functions. Oversight? Also, I?d add a ?`.`? at the end of the message, after all, it is a full sentence. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 25 23:03:58 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Dec 2013 23:03:58 -0000 Subject: [GHC] #5412: dataTypeConstrs gives unhelpful error message In-Reply-To: <051.725025e2f5a74cbcdbc139f819da79d1@haskell.org> References: <051.725025e2f5a74cbcdbc139f819da79d1@haskell.org> Message-ID: <066.59f41e72c3ed8bc473dedc436285921b@haskell.org> #5412: dataTypeConstrs gives unhelpful error message -------------------------------------+------------------------------------ Reporter: NeilMitchell | Owner: klangner Type: bug | Status: patch Priority: normal | Milestone: 7.6.2 Component: libraries/base | Version: 7.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by klangner): Yes you are right. The problem is that this kind of message can't be used in other places. So I was not sure if I should change other functions as well. On the other hand it would be nice to improve some other error messages since probably sooner or later this will return as new ticket. How do you think would be better? 1. Change only function from this ticket description 2. Change only messages where ADT is expected (4 places) and leave other messages intact. 3. Try to improve other error messages in this module as well. Third option will require more work and I'll probably need some help with the message texts. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 25 23:11:36 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Dec 2013 23:11:36 -0000 Subject: [GHC] #5412: dataTypeConstrs gives unhelpful error message In-Reply-To: <051.725025e2f5a74cbcdbc139f819da79d1@haskell.org> References: <051.725025e2f5a74cbcdbc139f819da79d1@haskell.org> Message-ID: <066.4855217ff5a142a1237b7deab3917180@haskell.org> #5412: dataTypeConstrs gives unhelpful error message -------------------------------------+------------------------------------ Reporter: NeilMitchell | Owner: klangner Type: bug | Status: patch Priority: normal | Milestone: 7.6.2 Component: libraries/base | Version: 7.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Go for 3! The message will always be of the kind ?Data.Data.... is not supported for ..., as it is not ...? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 27 01:58:31 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Dec 2013 01:58:31 -0000 Subject: [GHC] #8599: Deriving in associated data families ignores instance's constraints In-Reply-To: <047.15721e4f15b895eba1da55bf5a43686a@haskell.org> References: <047.15721e4f15b895eba1da55bf5a43686a@haskell.org> Message-ID: <062.5724e3860312fb1c9558f22cc97bac65@haskell.org> #8599: Deriving in associated data families ignores instance's constraints -------------------------------------+------------------------------------ Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by goldfire): * component: Compiler => Documentation Comment: This is by design, though quite non-trivially. The problem is caused by the confluence of two design decisions: 1. Associated data/newtype instances do not interact with any specified context to the enclosing class instance. 2. As the manual says in section 7.5.1, "each constraint in the inferred instance context must consist only of type variables, with no repetitions." In the case at hand, the inferred context would be `Eq (DF' a)`, which does not meet this criterion. The fact in (1) does not seem to be documented anywhere, which is why I'm relabeling this as a documentation bug. Changing this fact seems hard: do we want the context to be inherited by all data constructors of an associated data instance? How can the context interact with an associated type instance (without substantially changing the way type families work)? To me, the only place that the context should possibly be inherited is in derived instances, as the original report suggests. But, even here, its role would be unclear: is the context "fully-specified", like in a standalone-deriving instance? What if a larger context is necessary? What if a smaller one were sufficient? There are consistent points in this design space, but choosing one and articulating it might be hard, and somewhat arbitrary. Thoughts? If someone agrees with relabeling this as a documentation bug, I can update the stuff on data families when I return from holiday (Jan. 6). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 27 02:07:08 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Dec 2013 02:07:08 -0000 Subject: [GHC] #8630: Kind inference fails to account for associated types Message-ID: <047.41bd20303828e55f4c52d905682e1177@haskell.org> #8630: Kind inference fails to account for associated types -------------------------------------------+------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Consider this: {{{ {-# LANGUAGE PolyKinds, TypeFamilies, FlexibleInstances #-} class C a where type F a instance C a where type F a = a -> a }}} HEAD gives me {{{ Expected a type, but ?a? has kind ?k? In the type ?a -> a? In the type instance declaration for ?F? In the instance declaration for ?C a? }}} The problem is that the use of `(->)` in the RHS of the definition for the `F a` instance constrains `a` to be of kind `*`, but GHC does not propagate this information back to the instance head. This decision is in conflict with the behavior for ''class'' declarations (as opposed to ''instance'' declarations), where a type variable's use in the definition informs its kind in the head. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 27 03:05:48 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Dec 2013 03:05:48 -0000 Subject: [GHC] #8566: Panic with kindFunResult In-Reply-To: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> References: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> Message-ID: <061.faefa157fe2620ebd2c06710dfe4016d@haskell.org> #8566: Panic with kindFunResult -------------------------------------+------------------------------------ Reporter: dreixel | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: polykinds/T8566 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): I would say that `unA` in Pedro's (dreixel's) most recent example is indeed ill-typed -- it's an existential record selector, much like {{{ data Ex where MkEx :: { unEx :: [a] } -> Ex }}} The error message, though, could be improved. With `unEx`, GHC accepts the declaration but then prevents any use of `unEx` in an expression position. I propose that the same be done with `unA`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 27 03:39:32 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Dec 2013 03:39:32 -0000 Subject: [GHC] #8607: Invalid location reported for type constructors In-Reply-To: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> References: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> Message-ID: <059.cbd80358ab37d2fe960f83ed4b2d5977@haskell.org> #8607: Invalid location reported for type constructors -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Richard Eisenberg ): In [changeset:"724690f86f9bf92e886a785141c9ef423ddae05e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="724690f86f9bf92e886a785141c9ef423ddae05e" Revert "Simplify the plumbing for checkValidTyCl" This reverts commit 174577912de7a21b8fe01881a28f5aafce02b92e. This is part of the fix for #8607. Only reverting RdrHsSyn.lhs. Conflicts: compiler/parser/RdrHsSyn.lhs compiler/typecheck/TcTyClsDecls.lhs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 27 03:39:32 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Dec 2013 03:39:32 -0000 Subject: [GHC] #8607: Invalid location reported for type constructors In-Reply-To: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> References: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> Message-ID: <059.ad14c2ea077a536788ebb8ea00cd5d9f@haskell.org> #8607: Invalid location reported for type constructors -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Richard Eisenberg ): In [changeset:"e4afeedc5b8ac0f48cbeac09aa702c8d10433cdb/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e4afeedc5b8ac0f48cbeac09aa702c8d10433cdb" Fix #8607. The solution (after many false starts) is to change the behavior of hsLTyClDeclBinders. The idea is that the locations of the names that the parser generates should really be the names' locations, unlike what was done in 1745779... But, when the renamer is creating Names from the RdrNames, the locations stored in the Names should be the declarations' locations. This is now achieved in hsLTyClDeclBinders, which returns [Located name], but the location is that of the *declaration*, not the name itself. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 27 03:39:57 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Dec 2013 03:39:57 -0000 Subject: [GHC] #8607: Invalid location reported for type constructors In-Reply-To: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> References: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> Message-ID: <059.6af288c713d3b0eaba9e474bad737cfe@haskell.org> #8607: Invalid location reported for type constructors -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Richard Eisenberg ): In [changeset:"9e28639756bddb797ac99ec0613aeb2a70b0e4b9/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="9e28639756bddb797ac99ec0613aeb2a70b0e4b9" Error wibbles while fixing #8607. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 27 03:41:25 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Dec 2013 03:41:25 -0000 Subject: [GHC] #8607: Invalid location reported for type constructors In-Reply-To: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> References: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> Message-ID: <059.80c4d25aeb88f0759f94795a6aa01f80@haskell.org> #8607: Invalid location reported for type constructors -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by goldfire): * status: new => closed * resolution: => fixed Comment: See the commit message above for details -- somewhat different than my last Trac post on the subject. The solution I found was much cleaner than what I proposed here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 27 03:51:00 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Dec 2013 03:51:00 -0000 Subject: [GHC] #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? Message-ID: <047.7116b27539c649a1f73c0547859a3389@haskell.org> #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Nathan Howell posts this code: {{{ {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE RankNTypes #-} -- Uncomment to compile on GHC 7.8 -- {-# LANGUAGE ImpredicativeTypes #-} module Repro where import Control.Monad.Trans.Cont import Control.Monad.Trans.State.Lazy newtype AnyContT m a = AnyContT { unAnyContT :: forall r . ContT r m a } class MonadAnyCont b m where anyContToM :: (forall r . (a -> b r) -> b r) -> m a instance MonadAnyCont b (AnyContT m) where anyContToM _ = error "foo" data DecodeState = DecodeState newtype DecodeAST a = DecodeAST { unDecodeAST :: AnyContT (StateT DecodeState IO) a } deriving (MonadAnyCont IO) }}} Compiling on HEAD produces {{{ [1 of 1] Compiling Repro ( repro.hs, interpreted ) repro.hs:24:13: Cannot instantiate unification variable ?b0? with a type involving foralls: (forall r. (a1 -> IO r) -> IO r) -> DecodeAST a1 Perhaps you want ImpredicativeTypes In the expression: GHC.Prim.coerce (anyContToM :: (forall (r :: *). (a -> IO r) -> IO r) -> AnyContT (StateT DecodeState IO) a) :: forall (a :: *). (forall (r :: *). (a -> IO r) -> IO r) -> DecodeAST a In an equation for ?anyContToM?: anyContToM = GHC.Prim.coerce (anyContToM :: (forall (r :: *). (a -> IO r) -> IO r) -> AnyContT (StateT DecodeState IO) a) :: forall (a :: *). (forall (r :: *). (a -> IO r) -> IO r) -> DecodeAST a Failed, modules loaded: none. }}} Two questions: 1. Should we require users to specify !ImpredicativeTypes here? Or, should the !GeneralizedNewtypeDeriving mechanism (which sometimes is impredicative) just assume the extension? 2. Can we improve the error message? I'd like to note that the original example really ''does'' require impredicativity -- the question is whether and how to bother the user with this technicality. Small program note: I've done a lot of stuff with !GeneralizedNewtypeDeriving lately but am on holiday until Jan. 6, so don't expect responses! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 27 04:45:50 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Dec 2013 04:45:50 -0000 Subject: [GHC] #8632: ghc: panic! (the 'impossible' happened) Message-ID: <047.ca23d5f00b0151631633601b7e29344d@haskell.org> #8632: ghc: panic! (the 'impossible' happened) ----------------------------------+--------------------------------------- Reporter: jdoliner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- I got this message when trying to compile. It appears to be reproducible. Also I realize this is an outdate version of GHC so I'm going to update and see if it fixes itself. (GHC version 7.4.1 for x86_64-unknown-linux): compiler/rename/RnSource.lhs:429:14-81: Irrefutable pattern failed for pattern Data.Maybe.Just (inst_tyvars, _, SrcLoc.L _ cls, _) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 27 06:06:12 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Dec 2013 06:06:12 -0000 Subject: [GHC] #8633: template haskell mkName parses operator ^.. as a qualified operator Message-ID: <045.2a950246d7a5d48f7ac0bafa07aa7e88@haskell.org> #8633: template haskell mkName parses operator ^.. as a qualified operator ------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The operator `^..` (provided by lens) is parsed as the operator `.` from module `^`. In other words: {{{ import Language.Haskell.TH.Syntax main = case mkName "^.." of Name (OccName ".") (NameQ (ModName "^")) -> error "bug" Name (OccName "^..") NameS -> print "desired" }}} The context here is that I get `^..` out-of-scope when I try to use that operator in code that is handled by haskell-src-meta. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 27 09:52:40 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Dec 2013 09:52:40 -0000 Subject: [GHC] #5412: dataTypeConstrs gives unhelpful error message In-Reply-To: <051.725025e2f5a74cbcdbc139f819da79d1@haskell.org> References: <051.725025e2f5a74cbcdbc139f819da79d1@haskell.org> Message-ID: <066.9b300b4c000038e746356db65a0d5365@haskell.org> #5412: dataTypeConstrs gives unhelpful error message -------------------------------------+------------------------------------ Reporter: NeilMitchell | Owner: klangner Type: bug | Status: patch Priority: normal | Milestone: 7.6.2 Component: libraries/base | Version: 7.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by klangner): Ok. I fixed 8 previous messages. But I'm not sure what to do with this code: Case 1. {{{ instance Data Char where toConstr x = mkCharConstr charType x gunfold _ z c = case constrRep c of (CharConstr x) -> z x _ -> error "Data.Data.gunfold(Char)" dataTypeOf _ = charType }}} This instance is defined for Char type. So it is not possible to pass wrong type here. But I guess there still could be a problem with constructor representation. There are similar instances for other data types as well. Lots of them. Case 2. In function: '''repConstr''' exception is thrown when parameters have different data types. So there is a need for another message. I would say something like: "Data.Data.repConstr requires the same data type for both parameters." or similar. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 27 13:52:43 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Dec 2013 13:52:43 -0000 Subject: [GHC] #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? In-Reply-To: <047.7116b27539c649a1f73c0547859a3389@haskell.org> References: <047.7116b27539c649a1f73c0547859a3389@haskell.org> Message-ID: <062.6dab66a35576b5064c3b58ca42c1affd@haskell.org> #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * cc: mail@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 27 14:25:02 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Dec 2013 14:25:02 -0000 Subject: [GHC] #8607: Invalid location reported for type constructors In-Reply-To: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> References: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> Message-ID: <059.d16c52598d84c092fada3bd230762dad@haskell.org> #8607: Invalid location reported for type constructors -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by edsko): Replying to [comment:14 Richard Eisenberg ]: > The solution (after many false starts) is to change the behavior of > hsLTyClDeclBinders. The idea is that the locations of the names that > the parser generates should really be the names' locations, unlike > what was done in 1745779... But, when the renamer is creating Names > from the RdrNames, the locations stored in the Names should be the > declarations' locations. This is now achieved in hsLTyClDeclBinders, > which returns [Located name], but the location is that of the > *declaration*, not the name itself. Yes, this sounds like the Right Thing To Do. I have tested our code with this patch applied and it seems to work perfectly. Thank you very much! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 27 15:00:58 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Dec 2013 15:00:58 -0000 Subject: [GHC] #4210: LLVM: Dynamic Library Support In-Reply-To: <045.9da2e8588befc1a62c55be781a6ff87b@haskell.org> References: <045.9da2e8588befc1a62c55be781a6ff87b@haskell.org> Message-ID: <060.a349ad6800afacfcf30cca84c724e027@haskell.org> #4210: LLVM: Dynamic Library Support -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by bgamari): * difficulty: => Unknown Comment: I have some work relevant to this in https://github.com/bgamari/ghc/compare/llvm-intra-package. This branch both fixes the LLVM backend's support for dynamic linking and attempts to avoid dynamic references for intra-package calls. That being said, it's still a work in progress. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 27 15:18:44 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Dec 2013 15:18:44 -0000 Subject: [GHC] #8621: Pull request for inclusion in `unix' module of fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2) In-Reply-To: <050.ccaf00573c35157f252c17db26bcc258@haskell.org> References: <050.ccaf00573c35157f252c17db26bcc258@haskell.org> Message-ID: <065.2904732fc959719e5a8d733f711479fa@haskell.org> #8621: Pull request for inclusion in `unix' module of fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2) -------------------------------+------------------------------------------- Reporter: | Owner: jimenezrick | Status: new Type: task | Milestone: 7.10.1 Priority: normal | Version: 7.6.3 Component: | Keywords: libraries/unix | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 hour) Operating System: POSIX | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by jimenezrick): * milestone: 7.8.1 => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 27 15:20:17 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Dec 2013 15:20:17 -0000 Subject: [GHC] #8632: ghc: panic! (the 'impossible' happened) In-Reply-To: <047.ca23d5f00b0151631633601b7e29344d@haskell.org> References: <047.ca23d5f00b0151631633601b7e29344d@haskell.org> Message-ID: <062.abe83b3dd2d3b947fafe076484c5a4ab@haskell.org> #8632: ghc: panic! (the 'impossible' happened) ---------------------------------------+---------------------------------- Reporter: jdoliner | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by goldfire): * status: new => closed * resolution: => duplicate Comment: It looks like you forgot to attach the code that causes the error. In any case, this looks like the same problem as #7094, which was not reproducible in 7.6.x. If you find otherwise, please re-open the ticket. Thanks for reporting! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 27 15:22:09 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Dec 2013 15:22:09 -0000 Subject: [GHC] #8621: Pull request for inclusion in `unix' module of fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2) In-Reply-To: <050.ccaf00573c35157f252c17db26bcc258@haskell.org> References: <050.ccaf00573c35157f252c17db26bcc258@haskell.org> Message-ID: <065.d697beeb8358787a747713e033272063@haskell.org> #8621: Pull request for inclusion in `unix' module of fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2) -------------------------------+------------------------------------------- Reporter: | Owner: jimenezrick | Status: new Type: task | Milestone: 7.10.1 Priority: normal | Version: 7.6.3 Component: | Keywords: libraries/unix | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 hour) Operating System: POSIX | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by jimenezrick): All symbols are now conditionally exported. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 27 16:59:29 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Dec 2013 16:59:29 -0000 Subject: [GHC] #8634: Code valid in GHC 7.6 is impossible to move over GHC 7.7 (because of liberal coverage condition) Message-ID: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> #8634: Code valid in GHC 7.6 is impossible to move over GHC 7.7 (because of liberal coverage condition) ------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- == Abstract == Hi! I'm writing a compiler, which produces Haskell code. I've discovered it is impossible to keep currently used features / logic using GHC 7.7 instead of 7.6 Below is more detailed description of the problem: == The idea == I'm writing a [DSL][1], which compiles to Haskell. Users of this language can define own immutable data structures and associated functions. By associated function I mean a function, which belongs to a data structure. For example, user can write (in "pythonic" pseudocode): {{{#!python data Vector a: x,y,z :: a def method1(self, x): return x }}} (which is equivalent to the following code, but shows also, that associated functions beheva like type classes with open world assumption): {{{#!python data Vector a: x,y,z :: a def Vector.method1(self, x): return x }}} In this example, `method1` is a function associated with `Vector` data type, and can be used like `v.testid(5)` (where `v` is instance of `Vector` data type). I'm translating such code to Haskell code, but I'm facing a problem, which I'm trying to solve for a long time. == The problem == I'm trying to move the code from GHC 7.6 over GHC 7.7. The code works perfectly under GHC 7.6, but does not under GHC 7.7. I want to ask you how can I fix it to make it working in the new version of the compiler? == Example code == Lets see a simplified version of generated (by my compiler) Haskell code: {{{#!haskell {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE FunctionalDependencies #-} import Data.Tuple.OneTuple ------------------------------ -- data types ------------------------------ data Vector a = Vector {x :: a, y :: a, z :: a} deriving (Show) -- the Vector_testid is used as wrapper over a function "testid". newtype Vector_testid a = Vector_testid a ------------------------------ -- sample function, which is associated to data type Vector ------------------------------ testid (v :: Vector a) x = x ------------------------------ -- problematic function (described later) ------------------------------ testx x = call (method1 x) $ OneTuple "test" ------------------------------ -- type classes ------------------------------ -- type class used to access "method1" associated function class Method1 cls m func | cls -> m, cls -> func where method1 :: cls -> m func -- simplified version of type class used to "evaluate" functions based on -- their input. For example: passing empty tuple as first argument of `call` -- indicates evaluating function with default arguments (in this example -- the mechanism of getting default arguments is not available) class Call a b where call :: a -> b ------------------------------ -- type classes instances ------------------------------ instance (out ~ (t1->t1)) => Method1 (Vector a) Vector_testid out where method1 = (Vector_testid . testid) instance (base ~ (OneTuple t1 -> t2)) => Call (Vector_testid base) (OneTuple t1 -> t2) where call (Vector_testid val) = val ------------------------------ -- example usage ------------------------------ main = do let v = Vector (1::Int) (2::Int) (3::Int) -- following lines equals to a pseudocode of ` v.method1 "test" ` -- OneTuple is used to indicate, that we are passing single element. -- In case of more or less elements, ordinary tuples would be used. print $ call (method1 v) $ OneTuple "test" print $ testx v }}} The code compiles and works fine with GHC 7.6. When I'm trying to compile it with GHC 7.7, I'm getting following error: {{{ debug.hs:61:10: Illegal instance declaration for ?Method1 (Vector a) Vector_testid out? The liberal coverage condition fails in class ?Method1? for functional dependency: ?cls -> func? Reason: lhs type ?Vector a? does not determine rhs type ?out? In the instance declaration for ?Method1 (Vector a) Vector_testid out? }}} The error is caused by new rules of checking what functional dependencies can do, namely `liberal coverage condition` (as far as I know, this is `coverage condition` relaxed by using `-XUndecidableInstances`) == Some attemps to fix the problem == I was trying to overcome this problem by changing the definition of `Method1` to: {{{#!haskell class Method1 cls m func | cls -> m where method1 :: cls -> m func }}} Which resolves the problem with functional dependencies, but then the line: {{{#!haskell testx x = call (method1 x) $ OneTuple "test" }}} is not allowed anymore, causing a compile error (in both 7.6 and 7.7 versions): {{{ Could not deduce (Method1 cls m func0) arising from the ambiguity check for ?testx? from the context (Method1 cls m func, Call (m func) (OneTuple [Char] -> s)) bound by the inferred type for ?testx?: (Method1 cls m func, Call (m func) (OneTuple [Char] -> s)) => cls -> s at debug.hs:50:1-44 The type variable ?func0? is ambiguous When checking that ?testx? has the inferred type ?forall cls (m :: * -> *) func s. (Method1 cls m func, Call (m func) (OneTuple [Char] -> s)) => cls -> s? Probable cause: the inferred type is ambiguous }}} It is also impossible to solve this issue using type families (as far as I know). If we replace `Method1` type class and instances with following code (or simmilar): {{{#!haskell class Method1 cls m | cls -> m where type Func cls method1 :: cls -> m (Func cls) instance Method1 (Vector a) Vector_testid where type Func (Vector a) = (t1->t1) method1 = (Vector_testid . testid) }}} We would get obvious error `Not in scope: type variable ?t1?`, because type families does not allow to use types, which does not appear on LHS of type expression. == The final question == How can I make this idea work under GHC 7.7? I know the new `liberal coverage condition` allows GHC devs make some progress with type checking, but it should somehow be doable to port idea working in GHC 7.6 over never compiler version. (without forcing user of my DSL to introduce any further types - everything so far, like type class instances, I'm genarating using Template Haskell) Maybe is there a way to indroduce an extension, which will disable liberal coverage condition in such situations? There is also a StackOverflow discussion available, here: http://stackoverflow.com/questions/20778588/liberal-coverage-condition- introduced-in-ghc-7-7-breaks-code-valid-in-ghc-7-6 [1]: http://en.wikipedia.org/wiki/Domain-specific_language -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 27 18:05:11 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Dec 2013 18:05:11 -0000 Subject: [GHC] #8634: Code valid in GHC 7.6 is impossible to move over GHC 7.7 (because of liberal coverage condition) In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.a0ada3b0971bca8945f138a69f28fb7c@haskell.org> #8634: Code valid in GHC 7.6 is impossible to move over GHC 7.7 (because of liberal coverage condition) -----------------------------------+--------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: None/Unknown | Blocked By: Test Case: | Related Tickets: #1241, #2247, #8356 Blocking: | -----------------------------------+--------------------------------------- Changes (by rwbarton): * related: => #1241, #2247, #8356 Comment: {{{#!haskell class Method1 cls m func | cls -> m, cls -> func where ... }}} This means "for any type `cls`, there must be at most one type `func` for which there is an instance `Method1 cls m func`". (And the same for `m`.) {{{#!haskell instance (out ~ (t1->t1)) => Method1 (Vector a) Vector_testid out where ... }}} This defines instances like `Method1 (Vector Bool) Vector_testid (Int -> Int)`, `Method1 (Vector Bool) Vector_testid (Char -> Char)`, etc., so it violates the functional dependency. So, it was a (long-standing) bug that GHC 7.6 allowed this instance declaration. See the related tickets for further discussion. As for how to fix your program: it's hard to see what's going on with the `Call` type class, but can you try dropping both functional dependencies and writing {{{#!haskell instance (m ~ Vector_testid, out ~ (t1->t1)) => Method1 (Vector a) m out where ... }}} I'll leave this ticket open as several people have asked for an option to relax this functional dependency sanity condition, but I don't think it's a very good idea myself; the condition seems to usually catch real bugs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 27 18:08:14 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Dec 2013 18:08:14 -0000 Subject: [GHC] #8634: Code valid in GHC 7.6 is impossible to move over GHC 7.7 (because of liberal coverage condition) In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.effcd49597974b3a77a8c5c047ddc56f@haskell.org> #8634: Code valid in GHC 7.6 is impossible to move over GHC 7.7 (because of liberal coverage condition) -----------------------------------+--------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: None/Unknown | Blocked By: Test Case: | Related Tickets: #1241, #2247, #8356 Blocking: | -----------------------------------+--------------------------------------- Comment (by rwbarton): Perhaps the option to emulate the GHC 7.6 behavior could be called `-XDysfunctionalDependencies`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 27 18:42:19 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Dec 2013 18:42:19 -0000 Subject: [GHC] #8634: Code valid in GHC 7.6 is impossible to move over GHC 7.7 (because of liberal coverage condition) In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.e004e8c7c1f7e0f58ab2ea3feee12e2f@haskell.org> #8634: Code valid in GHC 7.6 is impossible to move over GHC 7.7 (because of liberal coverage condition) -----------------------------------+--------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: None/Unknown | Blocked By: Test Case: | Related Tickets: #1241, #2247, #8356 Blocking: | -----------------------------------+--------------------------------------- Comment (by danilo2): Replying to [comment:1 rwbarton]: First of all, thank you for your response and your comments :) > This means "for any type `cls`, there must be at most one type `func` for which there is an instance `Method1 cls m func`". (And the same for `m`.) Exactly - with one data type `cls` there could be "associated" only one function `func` with the name `method1`. > > {{{#!haskell > instance (out ~ (t1->t1)) => Method1 (Vector a) Vector_testid out where ... > }}} > > This defines instances like `Method1 (Vector Bool) Vector_testid (Int -> Int)`, `Method1 (Vector Bool) Vector_testid (Char -> Char)`, etc., so it violates the functional dependency. So, it was a (long-standing) bug that GHC 7.6 allowed this instance declaration. Hm, but if we assume, that there is only one such function `(a->a)` for a given `cls`, this should not be a problem? In such case, we are sure, that for `Vector a` and `Vector_testid` there is 0 or 1 functions with such signature (of course without such assumption this could be dangerous, but if a "power user" is writing lets say a DSL or is generating Haskell code and knows what he is doing, I see no point in preventing it. > See the related tickets for further discussion. I'll read them, thank you. > As for how to fix your program: it's hard to see what's going on with the `Call` type class (...) I'm really sorry for this - my example was probalby too simplified. Please take a look at this code (this is the same as above, but slighty modified and extended): {{{#!haskell {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE FunctionalDependencies #-} import Data.Tuple.OneTuple ------------------------------ data Vector a = Vector {x :: a, y :: a, z :: a} deriving (Show) newtype Vector_method1 a = Vector_method1 a newtype Vector_method2 a = Vector_method2 a ------------------------------ testid (v :: Vector a) x = x testf2 (v :: Vector a) x = (x,x) ------------------------------ testx x = call (method1 x) "test" ------------------------------ class Method1 cls m func | cls -> m, cls -> func where method1 :: cls -> m func class Method2 cls m func | cls -> m, cls -> func where method2 :: cls -> m func class Call ptr args result | ptr args -> result where call :: ptr -> args -> result ------------------------------ instance (out ~ (t1->t1)) => Method1 (Vector a) Vector_method1 out where method1 = (Vector_method1 . testid) instance (base ~ (t1 -> t2), out ~ t2) => Call (Vector_method1 base) (OneTuple t1) out where call (Vector_method1 val) (OneTuple arg) = val arg instance (base ~ (String -> t2), out ~ t2) => Call (Vector_method1 base) () out where call (Vector_method1 val) _ = val "default string" ------------------------------ instance (out ~ (t1->(t1,t1))) => Method2 (Vector a) Vector_method2 out where method2 = (Vector_method2 . testf2) instance (base ~ (t1 -> t2), out ~ t2) => Call (Vector_method2 base) (OneTuple t1) out where call (Vector_method2 val) (OneTuple arg) = val arg ------------------------------ main = do let v = Vector (1::Int) (2::Int) (3::Int) print $ call (method1 v) (OneTuple "test") print $ call (method1 v) () print $ call (method2 v) (OneTuple "test") }}} output: {{{#!haskell "test" "default string" ("test","test") }}} Here you can see, that we can call "method1" giving it `(OneTuple "test")` or `()`. The former passes simply one argument, while the later passes 0 arguments and the default value of "default string" is choosen instead. > (...) but can you try dropping both functional dependencies and writing > {{{#!haskell > instance (m ~ Vector_testid, out ~ (t1->t1)) => Method1 (Vector a) m out where ... > }}} Unfortunatelly I can not :( Look, `Vector_testid` indicates, that it holds "testid" method (it should be named `Vector_method1` instead - sorry for that typo. If we get more associated functions, we would have `Vector_method2`, `Vector_method3` etc, so we need to distinguish them - see the sample code in this comment. > I'll leave this ticket open as several people have asked for an option to relax this functional dependency sanity condition, but I don't think it's a very good idea myself; the condition seems to usually catch real bugs. I do not think to allow some "power users" to relax this condition, if such people know what they are doing. I completely agree, such condition usually catches a lot of bugs - so it should be enabled by default, but If you know, what you are doing, you've ben warned and you should make it off :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 27 19:22:38 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Dec 2013 19:22:38 -0000 Subject: [GHC] #8634: Code valid in GHC 7.6 is impossible to move over GHC 7.7 (because of liberal coverage condition) In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.9bbf8ed5e5408977ab3740d770c08dae@haskell.org> #8634: Code valid in GHC 7.6 is impossible to move over GHC 7.7 (because of liberal coverage condition) -----------------------------------+--------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: None/Unknown | Blocked By: Test Case: | Related Tickets: #1241, #2247, #8356 Blocking: | -----------------------------------+--------------------------------------- Comment (by rwbarton): > Unfortunatelly I can not :( Look, Vector_testid indicates, that it holds "testid" method (it should be named Vector_method1 instead - sorry for that typo. > If we get more associated functions, we would have Vector_method2, Vector_method3 etc, so we need to distinguish them - see the sample code in this comment. That doesn't seem to be a problem, as those will be instances of different classes `Method2`, `Method3`. {{{#!haskell instance (m ~ Vector_method1, out ~ (t1->t1)) => Method1 (Vector a) m out where method1 = (Vector_method1 . testid) instance (m ~ Vector_method2, out ~ (t1->(t1,t1))) => Method2 (Vector a) m out where method2 = (Vector_method2 . testf2) }}} With these changes your second program runs for me with GHC HEAD as long as I comment out `testx`--which is not used in the program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 27 19:37:55 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Dec 2013 19:37:55 -0000 Subject: [GHC] #8634: Code valid in GHC 7.6 is impossible to move over GHC 7.7 (because of liberal coverage condition) In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.25cac121d7f94bb806940051e46554fe@haskell.org> #8634: Code valid in GHC 7.6 is impossible to move over GHC 7.7 (because of liberal coverage condition) -----------------------------------+--------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: None/Unknown | Blocked By: Test Case: | Related Tickets: #1241, #2247, #8356 Blocking: | -----------------------------------+--------------------------------------- Comment (by danilo2): Replying to [comment:4 rwbarton]: > That doesn't seem to be a problem, as those will be instances of different classes `Method2`, `Method3`. Ouch, of course, you are right. I wanted to tell about the problem you've discovered later: > (...) > With these changes your second program runs for me with GHC HEAD as long as I comment out `testx`--which is not used in the program. And this is the problem I was talking about on StackOverflow and my original question - I marked it as "the problematic function" in GHC 7.7. It is now impossible, to make this function an "Vectora associated method" `method3`. We are generating all type class instances with template Haskell reifying needed functions to get their type signatures. If such function does not compile, reify would also fail. Even writing type class instances manually, it is impossible to make instances of `Method3` and `Call` for it, because it does not compile. By the way, this function will make more sense if it will be written as: {{{#!haskell testx v x = call (method1 x) (OneTuple "test") }}} , which means, calling associated "method1" of "x" with one argument of "test". It is still working in GHC 7.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 27 20:04:06 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Dec 2013 20:04:06 -0000 Subject: [GHC] #8634: Code valid in GHC 7.6 is impossible to move over GHC 7.7 (because of liberal coverage condition) In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.bdd1931f4ef77921c549478fd2a7dfab@haskell.org> #8634: Code valid in GHC 7.6 is impossible to move over GHC 7.7 (because of liberal coverage condition) -----------------------------------+--------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: None/Unknown | Blocked By: Test Case: | Related Tickets: #1241, #2247, #8356 Blocking: | -----------------------------------+--------------------------------------- Comment (by danilo2): Replying to [comment:4 rwbarton]: According to my previous comment, here is sample code, which uses the function `testx` as associated metthod `method2` to datatype `Vector` (it works under GHC 7.6 and is, as you've noted, impossible to convert to 7.7): {{{#!haskell {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE FunctionalDependencies #-} import Data.Tuple.OneTuple ------------------------------ data Vector a = Vector {x :: a, y :: a, z :: a} deriving (Show) newtype Vector_method1 a = Vector_method1 a newtype Vector_method2 a = Vector_method2 a ------------------------------ testid v x = x testf2 v x = (x,x) ------------------------------ -- problematic function: testx v x = call (method1 x) (OneTuple "test") ------------------------------ class Method1 cls m func | cls -> m, cls -> func where method1 :: cls -> m func class Method2 cls m func | cls -> m, cls -> func where method2 :: cls -> m func class Call ptr args result | ptr args -> result where call :: ptr -> args -> result ------------------------------ instance (out ~ (t1->t1)) => Method1 (Vector a) Vector_method1 out where method1 = (Vector_method1 . testid) instance (base ~ (t1 -> t2), out ~ t2) => Call (Vector_method1 base) (OneTuple t1) out where call (Vector_method1 val) (OneTuple arg) = val arg instance (base ~ (String -> t2), out ~ t2) => Call (Vector_method1 base) () out where call (Vector_method1 val) _ = val "default string" ------------------------------ instance ( Call (m func0) (OneTuple String) b , Method1 a m func0 , out ~ (a -> b) ) => Method2 (Vector v) Vector_method2 out where method2 = (Vector_method2 . testx) instance (base ~ (t1 -> t2), out ~ t2) => Call (Vector_method2 base) (OneTuple t1) out where call (Vector_method2 val) (OneTuple arg) = val arg ------------------------------ main = do let v = Vector (1::Int) (2::Int) (3::Int) print $ call (method1 v) (OneTuple "test") print $ call (method1 v) () print $ call (method2 v) (OneTuple v) }}} Output: {{{#!haskell "test" "default string" "test" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 27 20:40:25 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Dec 2013 20:40:25 -0000 Subject: [GHC] #4210: LLVM: Dynamic Library Support In-Reply-To: <045.9da2e8588befc1a62c55be781a6ff87b@haskell.org> References: <045.9da2e8588befc1a62c55be781a6ff87b@haskell.org> Message-ID: <060.113c71a914c534353ca1d6bedb6a32a8@haskell.org> #4210: LLVM: Dynamic Library Support -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: patch Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by bgamari): * cc: bgamari@? (added) * status: new => patch Comment: I just sent this [http://www.haskell.org/pipermail/ghc- devs/2013-December/003531.html message] to the list characterizing the behavior of the NCG and LLVM backends in handling dynamic references. In short, the NCG and LLVM backends both handle intra-package references efficiently. That is, the branch I cited in comment 24 shouldn't be necessary. In this case, all we need is the fixes in this [https://github.com/bgamari/ghc/commits/llvm-dynamic branch] for functional dynamic linking with the LLVM backend. This has been tested on both x86_64 and ARM. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 27 21:20:54 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Dec 2013 21:20:54 -0000 Subject: [GHC] #8635: GHC optimisation flag ignored when importing a local module with derived type classes Message-ID: <051.b56cbb747db73c4a6033f73a503b3d1a@haskell.org> #8635: GHC optimisation flag ignored when importing a local module with derived type classes ------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Given Foo.hs and Bar.hs: {{{ module Foo where data Food = Food -- deriving Eq {-# OPTIONS_GHC -O2 -ddump-simpl #-} module Bar where import Foo bar :: Int -> Bool bar x = x == 72 }}} If I run: {{{ ghc --make Bar -fforce-recomp }}} I get (snipped): {{{ Bar.bar = \ (x_afk :: GHC.Types.Int) -> case x_afk of _ { GHC.Types.I# x1_alo -> case x1_alo of _ { __DEFAULT -> GHC.Types.False; 72 -> GHC.Types.True } } }}} `bar` now looks pretty well optimised. However, if I uncomment the `deriving Eq` I get: {{{ Bar.bar1 = GHC.Types.I# 72 Bar.bar2 = GHC.Classes.== @ GHC.Types.Int GHC.Classes.$fEqInt Bar.bar = \ (x_amD :: GHC.Types.Int) -> Bar.bar2 x_amD Bar.bar1 }}} Now `bar` looks like terrible code, using dictionaries, boxing etc. It seems adding `deriving` in the imported and unused module makes it ignore the optimisation level. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 27 21:21:18 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Dec 2013 21:21:18 -0000 Subject: [GHC] #8635: GHC optimisation flag ignored when importing a local module with derived type classes In-Reply-To: <051.b56cbb747db73c4a6033f73a503b3d1a@haskell.org> References: <051.b56cbb747db73c4a6033f73a503b3d1a@haskell.org> Message-ID: <066.9d9329f0c94ea08be8fa8c176aa2a1c5@haskell.org> #8635: GHC optimisation flag ignored when importing a local module with derived type classes -------------------------------------+------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by NeilMitchell): * cc: ndmitchell@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 28 03:12:13 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Dec 2013 03:12:13 -0000 Subject: [GHC] #5361: regSpill: out of spill slots! In-Reply-To: <049.cbc3b6a1173f092cb2619a218adec7c2@haskell.org> References: <049.cbc3b6a1173f092cb2619a218adec7c2@haskell.org> Message-ID: <064.0ccc0860f7dc5f10925c35d27b0c4690@haskell.org> #5361: regSpill: out of spill slots! -------------------------------------+------------------------------------- Reporter: markwright | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.1 Resolution: worksforme | Keywords: regSpill panic Operating System: Linux | impossible Type of failure: Compile-time | Architecture: x86_64 (amd64) crash | Difficulty: Unknown Test Case: | Blocked By: http://hackage.haskell.org/package/SHA| Related Tickets: Blocking: | -------------------------------------+------------------------------------- Changes (by kazu-yamamoto): * cc: kazu@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 28 03:15:11 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Dec 2013 03:15:11 -0000 Subject: [GHC] #5361: regSpill: out of spill slots! In-Reply-To: <049.cbc3b6a1173f092cb2619a218adec7c2@haskell.org> References: <049.cbc3b6a1173f092cb2619a218adec7c2@haskell.org> Message-ID: <064.a272514ef6db7d15458dab8413b4dc03@haskell.org> #5361: regSpill: out of spill slots! -------------------------------------+------------------------------------- Reporter: markwright | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.1 Resolution: | Keywords: regSpill panic Operating System: Linux | impossible Type of failure: Compile-time | Architecture: x86_64 (amd64) crash | Difficulty: Unknown Test Case: | Blocked By: http://hackage.haskell.org/package/SHA| Related Tickets: Blocking: | -------------------------------------+------------------------------------- Changes (by kazu-yamamoto): * status: closed => new * resolution: worksforme => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 28 03:16:25 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Dec 2013 03:16:25 -0000 Subject: [GHC] #5361: regSpill: out of spill slots! In-Reply-To: <049.cbc3b6a1173f092cb2619a218adec7c2@haskell.org> References: <049.cbc3b6a1173f092cb2619a218adec7c2@haskell.org> Message-ID: <064.a802442069f2d5c620beb0f88ec47613@haskell.org> #5361: regSpill: out of spill slots! -------------------------------------+------------------------------------- Reporter: markwright | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.1 Resolution: | Keywords: regSpill panic Operating System: Linux | impossible Type of failure: Compile-time | Architecture: x86_64 (amd64) crash | Difficulty: Unknown Test Case: | Blocked By: http://hackage.haskell.org/package/SHA| Related Tickets: Blocking: | -------------------------------------+------------------------------------- Comment (by kazu-yamamoto): I can reproduce this on 32 bit Linux: {{{ % ghc --version The Glorious Glasgow Haskell Compilation System, version 7.7.20131202 % cabal install SHA Configuring SHA-1.6.1... Building SHA-1.6.1... Failed to install SHA-1.6.1 Last 10 lines of the build log ( /home/kazu/.cabal/logs/SHA-1.6.1.log ): Preprocessing library SHA-1.6.1... [1 of 1] Compiling Data.Digest.Pure.SHA ( Data/Digest/Pure/SHA.hs, dist/build/Data/Digest/Pure/SHA.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.7.20131202 for i386-unknown-linux): regSpill: out of spill slots! regs to spill = 1129 slots left = 677 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Error: some packages failed to install: SHA-1.6.1 failed during the building phase. The exception was: ExitFailure 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 28 04:49:53 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Dec 2013 04:49:53 -0000 Subject: [GHC] #8633: template haskell mkName parses operator ^.. as a qualified operator In-Reply-To: <045.2a950246d7a5d48f7ac0bafa07aa7e88@haskell.org> References: <045.2a950246d7a5d48f7ac0bafa07aa7e88@haskell.org> Message-ID: <060.6ffa75ab7e82605c13b719b81a8bf29a@haskell.org> #8633: template haskell mkName parses operator ^.. as a qualified operator -------------------------------------+------------------------------------ Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by aavogt): Attached is a mkName function, which does not have the issues above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 28 10:29:56 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Dec 2013 10:29:56 -0000 Subject: [GHC] #8635: GHC optimisation flag ignored when importing a local module with derived type classes In-Reply-To: <051.b56cbb747db73c4a6033f73a503b3d1a@haskell.org> References: <051.b56cbb747db73c4a6033f73a503b3d1a@haskell.org> Message-ID: <066.9f918cdadf8ebd263b645d796af459b3@haskell.org> #8635: GHC optimisation flag ignored when importing a local module with derived type classes -------------------------------------+------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): I agree this is strange behaviour. Here's why it happens. * With `--make` GHC reads each library interface file only once, e.g. that defining equality for `Int`. * Without `-O` (i.e. with `-O0`), GHC sets `-fignore-interface-pragmas`. * When reading an interface file with `-fignore-interface-pragmas`, GHC skips all the unfoldings and other inessential info. * Without the `deriving` stuff, there's no reason to read the crucial interface file when compiling `Foo`. So it's read when compiling `Bar`, and hence when `-O` is set. * With the `deriving` clause, the crucial interface file is read when compiling `Foo`, but the unfoldings are skipped, and hence are unavailable when compiling `Bar`. You can get the behaviour you want by adding `-fno-ignore-interface- pragmas`. Maybe this should be the case with `--make`? But that choice would have the following downside: with `-fno-ignore-interface-pragamas` all unfoldings are read in, and may subsequently get used even by the modest optimisation done with `-O0`. Mind you, that ''might'' conceivably be a win. Maybe compile time and binary size would only increase marginally, but execution time would fall significantly? Would someone like to try the effect on compile times, binary size, and execution time, of using `-fno-ignore-interface-pragmas` with `-O0`? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 28 13:09:51 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Dec 2013 13:09:51 -0000 Subject: [GHC] #8566: Panic with kindFunResult In-Reply-To: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> References: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> Message-ID: <061.87081e0af6d3460eda3778e477825888@haskell.org> #8566: Panic with kindFunResult -------------------------------------+------------------------------------ Reporter: dreixel | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: polykinds/T8566 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): I had a look at this. I don't agree with Richard: it should typecheck. This `unT` is well typed, despite the GADT: {{{ type family F (a :: *) :: * data T a where MkT :: F a -> T [a] unT :: T [b] -> F b unT (MkT x) = x }}} Here we see that {{{ MkT :: forall u. forall a. (u ~ [a]) => F a -> T u }}} So the 'a' is existential. But from the pattern match we get a Given constraint `[b] ~ [a]`, and we can decompose that to, in effect, determine the existential via a Given equality `b~a`. However that doesn't work in the poly-kinded case of this ticket because the constraint we get is something like `APP k1 (b:k1) ~ APP k2 (a:k2)`. The trouble is that we don't have kind equalities (yet!), so GHC currently decomposes the Given APP constraint, but then silently discards new Given constraint `k1~k2` (since we don't have kind equalities) and `b~a` (because they have incompatible kinds). See `Note [Do not create Given kind equalities]` in `TcSMonad`. The net result is that we can't prove an equality that we "ought" to be able to prove, giving a confusing error message. I do agree with Richard that (until we get kind equalities) it would be better to treat it like an existential record selector, rather than produce the opaque error message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 28 13:54:22 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Dec 2013 13:54:22 -0000 Subject: [GHC] #8566: Given kind equalities are discarded (was: Panic with kindFunResult) In-Reply-To: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> References: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> Message-ID: <061.1396ca35ff9b9637e4daeda531363671@haskell.org> #8566: Given kind equalities are discarded -------------------------------------+------------------------------------ Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: polykinds/T8566 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * status: closed => new * resolution: fixed => Comment: Hmm. It occurs to me that with these GADTs it isn't just record selectors that are going to bad on us. Consider {{{ -- Proxy :: forall k. k -> * data T a where MkT :: Proxy b -> T (Proxy b) }}} So the real type of `MkT` is (putting in the kinds) {{{ MkT :: forall u. forall k, b:k. (u ~ Proxy k b) => Proxy k b -> T u }}} Now that `k` is existential. So pattern-matching is going to be problematic. For example, if we write {{{ f :: forall kc, c:kc. T (Proxy kc c) -> Proxy kc c f (MkT x) = x }}} we'll get a Given equality `Proxy kc c ~ Proxy k b`, where the 'k' and 'b' are existentially bound; since we can't make use of such Given equalities, we'll get obscure failures. I rather think that we should '''reject any type signature (including GADT ones) with an equality constraint that mentions a kind variable'''. That would be more restrictive, but it is at least clear. How bad would that be? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 28 14:28:27 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Dec 2013 14:28:27 -0000 Subject: [GHC] #8630: Kind inference fails to account for associated types In-Reply-To: <047.41bd20303828e55f4c52d905682e1177@haskell.org> References: <047.41bd20303828e55f4c52d905682e1177@haskell.org> Message-ID: <062.22cfca5a46eaf020ebe7a3d514f5c887@haskell.org> #8630: Kind inference fails to account for associated types --------------------------------------------+------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): I suppose you are right here. But I think it'll take quite a bit of code to do the Right Thing here. The Right Thing is, I suppose, to walk over the associated-type declarations of the instance, and gather any kind constraints they generate. But consider something like this: {{{ instance C (T a) where type F (T a) b = b -> a }}} Here we must bring 'b' into scope before doing kind-checking on the RHS of the type instance. And then there are data families. This all duplicates the code we subsequently use for typechecking those type/data instances. Fiddly. Moreover, you could argue the same for ''value'' declarations too: {{{ instance C (T a) where op x y = [x, y::a -> a] }}} There's a type signature deep in the term that constrains the kind of 'a'. It would arguably be inconsistent to look at ''type'' instances but not ''value'' instances. And we really really are not going to look into the value terms! So I'm not sure it's worth fixing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 28 19:38:25 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Dec 2013 19:38:25 -0000 Subject: [GHC] #8635: GHC optimisation flag ignored when importing a local module with derived type classes In-Reply-To: <051.b56cbb747db73c4a6033f73a503b3d1a@haskell.org> References: <051.b56cbb747db73c4a6033f73a503b3d1a@haskell.org> Message-ID: <066.73032d55e1a89d2a5124499e63292c2e@haskell.org> #8635: GHC optimisation flag ignored when importing a local module with derived type classes -------------------------------------+------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by NeilMitchell): Thanks for the explanation. As long as it doesn't happen at `-O1` (which it won't, from your explanation) it won't actually matter to me in practice. It does mean that at `-O0` the effect of things like `-O2` is dependent on what modules you import, what functions they use, what order things are processed by `ghc --make` etc. I suspect that inlining very small things like `$` can only be a win in terms of code size. Seeing them in the output, even at `-O0`, was a little surprising (although entirely understandable). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 29 13:55:12 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Dec 2013 13:55:12 -0000 Subject: [GHC] #3990: UNPACK doesn't unbox data families In-Reply-To: <041.50e84dc9fb16fae63af270459584532c@haskell.org> References: <041.50e84dc9fb16fae63af270459584532c@haskell.org> Message-ID: <056.9a84f98f2d53629ddb5e716069ed17d2@haskell.org> #3990: UNPACK doesn't unbox data families --------------------------------------------+------------------------------ Reporter: rl | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by sjoerd_visscher): What about closed data families? GHC could check that every instance is unpackable. Then this would work: {{{ data Nat = Z | S Nat data family Vec (size :: Nat) where Vec Z = Nil Vec (S n) = Cons {-# UNPACK #-} !Double {-# UNPACK #-} !(Vec n) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 29 15:01:31 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Dec 2013 15:01:31 -0000 Subject: [GHC] #5412: dataTypeConstrs gives unhelpful error message In-Reply-To: <051.725025e2f5a74cbcdbc139f819da79d1@haskell.org> References: <051.725025e2f5a74cbcdbc139f819da79d1@haskell.org> Message-ID: <066.4d9210c50f9a3a775ba64f73bde7bc39@haskell.org> #5412: dataTypeConstrs gives unhelpful error message -------------------------------------+------------------------------------ Reporter: NeilMitchell | Owner: klangner Type: bug | Status: patch Priority: normal | Milestone: 7.6.2 Component: libraries/base | Version: 7.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Case 1. A better error message here would be `"Data.Data.gunfold: Constructor " ++ show c ++ " is not of type Char"`. But if you don?t feel like working on that class of error message right now you can concentrate on the others and skip these for now. Case 2. Sounds good. Or maybe `"Data.Data.repConstr: The given ConstrRep does not fit to the given DataType"`, possibly extended with actually showing both parameters, or using `dataTypeName`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 30 05:06:23 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Dec 2013 05:06:23 -0000 Subject: [GHC] #4210: LLVM: Dynamic Library Support In-Reply-To: <045.9da2e8588befc1a62c55be781a6ff87b@haskell.org> References: <045.9da2e8588befc1a62c55be781a6ff87b@haskell.org> Message-ID: <060.86cef69c3d866409b9988e15f1df2abf@haskell.org> #4210: LLVM: Dynamic Library Support -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: patch Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by dterei): OK, so just to check, the issue to fix is just the one initially mentioned of using @object annotations instead of @function annotations? Sounds good to me -- I'll pull in the patches soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 30 12:11:07 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Dec 2013 12:11:07 -0000 Subject: [GHC] #8603: GHC crashes on some code using StateT monad transformer In-Reply-To: <049.faef5c68395d742a3684db2c63ac8cd1@haskell.org> References: <049.faef5c68395d742a3684db2c63ac8cd1@haskell.org> Message-ID: <064.78f04d142e50ec5ed72c9a173a234839@haskell.org> #8603: GHC crashes on some code using StateT monad transformer --------------------------------------------+------------------------------ Reporter: person1729 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time crash | (amd64) Test Case: Attached | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"8721743e88f4c8c385eb0ceb0ca6804b2143a8fa/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8721743e88f4c8c385eb0ceb0ca6804b2143a8fa" Re-factor TcCanonical (again), fixes Trac #8603 This is a substantial refactoring of the canonicaliser. The proximate cause was that we were sometimes failing to correctly orient a tyvar/tyvar equality (x ~ y), because the kind of x or y was not fully zonked at the moment we compared them. That in turn led me to look closely at the way that canEvNC (which decomposes equalities) worked. * The big change is that the 'reOrient' and 'classify' functions are gone, along with classify's 'TypeClassifier' return type. Instead the re-orientation is built into canEqNC. When we find a type variable we divert into canEqTyVar, and so on, very much as in TcUnify. * TcCanonical.canEqTyVar, canEqLeafFun, etc now carry a SwapFlag (to reduce duplication), just as in TcUnify; now SwapFlag itself is defined in BasicTypes * I renamed TcSMonad.rewriteCtFlavor to rewriteEvidence, * I added a new specialised version of rewriteEvidence, called TcSMonad.rewriteEqEvidence. It is easier to use, and removes the crafty but brain-mangling higher order casts that we were using before. The result is not exactly simpler, but it's pretty clear and, I think, significantly more efficient. And it fixes Trac #8603! }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 30 12:15:45 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Dec 2013 12:15:45 -0000 Subject: [GHC] #8633: template haskell mkName parses operator ^.. as a qualified operator In-Reply-To: <045.2a950246d7a5d48f7ac0bafa07aa7e88@haskell.org> References: <045.2a950246d7a5d48f7ac0bafa07aa7e88@haskell.org> Message-ID: <060.5e5508a91e7edea3c971b08a27ba9495@haskell.org> #8633: template haskell mkName parses operator ^.. as a qualified operator -------------------------------------+------------------------------------ Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"3fef8e4094c8d0c58bad2604ecaee93d797ccbd1/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="3fef8e4094c8d0c58bad2604ecaee93d797ccbd1" Test Trac #8633 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 30 12:15:45 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Dec 2013 12:15:45 -0000 Subject: [GHC] #8603: GHC crashes on some code using StateT monad transformer In-Reply-To: <049.faef5c68395d742a3684db2c63ac8cd1@haskell.org> References: <049.faef5c68395d742a3684db2c63ac8cd1@haskell.org> Message-ID: <064.8caef584b9f6706184bb798adca6dbcd@haskell.org> #8603: GHC crashes on some code using StateT monad transformer --------------------------------------------+------------------------------ Reporter: person1729 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time crash | (amd64) Test Case: Attached | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"b34bee3a45204ff43fa31e9dee3a23a74aa252db/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="b34bee3a45204ff43fa31e9dee3a23a74aa252db" Test Trac #8603 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 30 12:27:55 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Dec 2013 12:27:55 -0000 Subject: [GHC] #8636: Infix declaration on operators ending on backslash Message-ID: <049.f087d7cb3e1ecaa0bf93cea006d4da7c@haskell.org> #8636: Infix declaration on operators ending on backslash ----------------------------+---------------------------------------------- Reporter: | Owner: jcristovao | Status: new Type: bug | Milestone: Priority: normal | Version: 7.7 Component: Compiler | Operating System: Linux Keywords: | Type of failure: GHC rejects valid program Architecture: x86_64 | Test Case: (amd64) | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- Hi, I was trying the latest GHC Head (version 7.7.20131227), when I noticed a regression. I don't know if this is intended behaviour or not. This compiled ok under 7.6.3 {{{ (?&&\) :: (Monoid a) => a -> (a -> Bool) -> a (?&&\) value f = if f value then value else mempty infixl 1 ?&&\ }}} Under 7.7, the infixl declaration only works if I double escape it. {{{ infixl 1 ?&&\\ }}} Is this intended? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 30 12:27:56 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Dec 2013 12:27:56 -0000 Subject: [GHC] #8637: Infix declaration on operators ending on backslash Message-ID: <049.2cd5e7f6a1d86ee9948a2d858f74ba1f@haskell.org> #8637: Infix declaration on operators ending on backslash ----------------------------+---------------------------------------------- Reporter: | Owner: jcristovao | Status: new Type: bug | Milestone: Priority: normal | Version: 7.7 Component: Compiler | Operating System: Linux Keywords: | Type of failure: GHC rejects valid program Architecture: x86_64 | Test Case: (amd64) | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- Hi, I was trying the latest GHC Head (version 7.7.20131227), when I noticed a regression. I don't know if this is intended behaviour or not. This compiled ok under 7.6.3 {{{ (?&&\) :: (Monoid a) => a -> (a -> Bool) -> a (?&&\) value f = if f value then value else mempty infixl 1 ?&&\ }}} Under 7.7, the infixl declaration only works if I double escape it. {{{ infixl 1 ?&&\\ }}} Is this intended? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 30 12:29:32 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Dec 2013 12:29:32 -0000 Subject: [GHC] #8603: GHC crashes on some code using StateT monad transformer In-Reply-To: <049.faef5c68395d742a3684db2c63ac8cd1@haskell.org> References: <049.faef5c68395d742a3684db2c63ac8cd1@haskell.org> Message-ID: <064.55605d6c67f2d16242c15b91cca2885b@haskell.org> #8603: GHC crashes on some code using StateT monad transformer ------------------------------------------------+-------------------------- Reporter: person1729 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time crash | (amd64) Test Case: typecheck/should_fail/T8603 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by simonpj): * status: new => closed * testcase: Attached => typecheck/should_fail/T8603 * resolution: => fixed Comment: Thanks for identifying this bug! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 30 12:30:29 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Dec 2013 12:30:29 -0000 Subject: [GHC] #8637: Infix declaration on operators ending on backslash In-Reply-To: <049.2cd5e7f6a1d86ee9948a2d858f74ba1f@haskell.org> References: <049.2cd5e7f6a1d86ee9948a2d858f74ba1f@haskell.org> Message-ID: <064.e3aca5e047d848da381e4c49af652446@haskell.org> #8637: Infix declaration on operators ending on backslash ----------------------------------------------+---------------------------- Reporter: jcristovao | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects valid program | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by jcristovao): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 30 12:31:54 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Dec 2013 12:31:54 -0000 Subject: [GHC] #8633: template haskell mkName parses operator ^.. as a qualified operator In-Reply-To: <045.2a950246d7a5d48f7ac0bafa07aa7e88@haskell.org> References: <045.2a950246d7a5d48f7ac0bafa07aa7e88@haskell.org> Message-ID: <060.d9e88c62fc01c1c291ad586c3b53ff70@haskell.org> #8633: template haskell mkName parses operator ^.. as a qualified operator -------------------------------------+------------------------------------ Reporter: aavogt | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: th/T8633 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * status: new => closed * testcase: => th/T8633 * resolution: => fixed Comment: Thanks for the patch. I adjusted it a bit {{{ commit 21a48605d856ca334bb3a018e02255349d69a8c4 Author: Simon Peyton Jones Date: Sat Dec 28 11:05:31 2013 +0000 Improve mkName, so that it correctly parses the name ^.. This fixes Trac #8633; thanks to aavogt for a first draft. >--------------------------------------------------------------- 21a48605d856ca334bb3a018e02255349d69a8c4 Language/Haskell/TH/Syntax.hs | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-) diff --git a/Language/Haskell/TH/Syntax.hs b/Language/Haskell/TH/Syntax.hs index f3868d1..3606f9d 100644 --- a/Language/Haskell/TH/Syntax.hs +++ b/Language/Haskell/TH/Syntax.hs @@ -24,7 +24,7 @@ import Data.IORef import System.IO.Unsafe ( unsafePerformIO ) import Control.Monad (liftM) import System.IO ( hPutStrLn, stderr ) -import Data.Char ( isAlpha ) +import Data.Char ( isAlpha, isAlphaNum, isUpper ) import Data.Word ( Word8 ) ----------------------------------------------------- @@ -758,17 +758,33 @@ mkName str = split [] (reverse str) where split occ [] = Name (mkOccName occ) NameS - split occ ('.':rev) | not (null occ), - not (null rev), head rev /= '.' + split occ ('.':rev) | not (null occ) + , is_rev_mod_name rev = Name (mkOccName occ) (NameQ (mkModName (reverse rev))) -- The 'not (null occ)' guard ensures that -- mkName "&." = Name "&." NameS - -- The 'rev' guards ensure that + -- The 'is_rev_mod' guards ensure that -- mkName ".&" = Name ".&" NameS + -- mkName "^.." = Name "^.." NameS -- Trac #8633 -- mkName "Data.Bits..&" = Name ".&" (NameQ "Data.Bits") -- This rather bizarre case actually happened; (.&.) is in Data.Bits split occ (c:rev) = split (c:occ) rev + -- Recognises a reversed module name xA.yB.C, + -- with at least one component, + -- and each component looks like a module name + -- (i.e. non-empty, starts with capital, all alpha) + is_rev_mod_name rev_mod_str + | (compt, rest) <- break (== '.') rev_mod_str + , not (null compt), isUpper (last compt), all is_mod_char compt + = case rest of + [] -> True + (_dot : rest') -> is_rev_mod_name rest' + | otherwise + = False + + is_mod_char c = isAlphaNum c || c == '_' || c == '\'' + -- | Only used internally mkNameU :: String -> Uniq -> Name mkNameU s (I# u) = Name (mkOccName s) (NameU u) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 30 15:07:36 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Dec 2013 15:07:36 -0000 Subject: [GHC] #8638: Optimize by demoting "denormalized" Integers (i.e. J# -> S#) Message-ID: <042.e2b4c372649ba443c83acd6104d8dbd7@haskell.org> #8638: Optimize by demoting "denormalized" Integers (i.e. J# -> S#) ------------------------------+-------------------------------------------- Reporter: hvr | Owner: hvr Type: feature | Status: new request | Milestone: 7.8.1 Priority: normal | Version: 7.7 Component: libraries | Operating System: Unknown/Multiple (other) | Type of failure: Runtime performance bug Keywords: integer- | Test Case: gmp | Blocking: Architecture: | Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- In the course of a recent [discussion on reddit](http://www.reddit.com/r/haskell/comments/1twtvm/the_problem_with_integer/) it was highlighted, that `integer-gmp` doesn't try to demote `J#` to the more efficient `S#` if even though they would fit. The attached proof-of-concept patch introduces a "smart" `J#` constructor which constructs a `S#` instead if possible: {{{ #!hs -- | Demote 'J#' to 'S#' if possible. See also 'smartJ#'. toSmall :: Integer -> Integer toSmall i@(S# _) = i toSmall (J# 0# _) = S# 0# toSmall (J# 1# mb#) | isTrue# (v ># 0#) = S# v where v = indexIntArray# mb# 0# toSmall (J# -1# mb#) | isTrue# (v <# 0#) = S# v where v = negateInt# (indexIntArray# mb# 0#) toSmall i = i -- | Smart 'J#' constructor which tries to construct 'S#' if possible smartJ# :: Int# -> ByteArray# -> Integer smartJ# s# mb# = toSmall (J# s# mb#) }}} And replaces a couple of `J#`-constructions which are likely to produce a `S#`-fitting `Integer`. A `nofib` comparison for vanilla GHC HEAD vs patched GHC HEAD is attached for further discussion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 30 15:11:12 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Dec 2013 15:11:12 -0000 Subject: [GHC] #8624: -ddump-splices-file In-Reply-To: <048.f5eead94409241401357105f8bb65a4f@haskell.org> References: <048.f5eead94409241401357105f8bb65a4f@haskell.org> Message-ID: <063.4a4a81e64e1217d3d69f411141c87218@haskell.org> #8624: -ddump-splices-file -------------------------------------+------------------------------------ Reporter: GregWeber | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): This seems like a very reasonable thing to do. I'm not volunteering to do it myself, but I'll gladly support anyone who does; I know how the TH implementation works. The "untyped" splices are expanded by the renamer, and the "typed" ones by the type checker. So if you want to see all splices expanded, you need to look at the output of the type checker. Fortunately that's not difficult: it is more or less what `-ddump-tc` shows you. So to a first approximation, what you want is to take the output of `-ddump-tc` and put it in a file. But there are always details: * `-ddump-tc` is, as its name implies, a debugging flag. We have not taken care to ensure that the pretty-printed output is fully-parsable Haskell. It should be, but you'd need to work on the `Outputable` instances for `HsSyn` to make it fully working. * The type checker "elaborates" the code by adding type abstractions and applications, dictionary abstractions and applications, and so on. For debugging purposes you want to see this; but for your purposes you want to suppress all the elaboration stuff. I've been careful to use different data constructors in `HsSyn` for elaboration code, so it should be easy to suppress it. But to do that you need to pass a flag into the pretty printer (to tell it whether to suppress it) and we need to think about how to do that. You definitely don't want to write two pretty-printers! The usual process is to start a GHC Trac wiki page to describe the (user- facing) specification, and sketch any implementation details or choices. And use the ticket or `ghc-devs` to discuss. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 30 15:14:26 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Dec 2013 15:14:26 -0000 Subject: [GHC] #8638: Optimize by demoting "denormalized" Integers (i.e. J# -> S#) In-Reply-To: <042.e2b4c372649ba443c83acd6104d8dbd7@haskell.org> References: <042.e2b4c372649ba443c83acd6104d8dbd7@haskell.org> Message-ID: <057.32ea076232306ba5251d27cb0d9a6c22@haskell.org> #8638: Optimize by demoting "denormalized" Integers (i.e. J# -> S#) --------------------------------------------+------------------------------ Reporter: hvr | Owner: hvr Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.7 Resolution: | Keywords: integer- Operating System: Unknown/Multiple | gmp Type of failure: Runtime performance bug | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Description changed by hvr: Old description: > In the course of a recent [discussion on > reddit](http://www.reddit.com/r/haskell/comments/1twtvm/the_problem_with_integer/) > it was highlighted, that `integer-gmp` doesn't try to demote `J#` to the > more efficient `S#` if even though they would fit. > > The attached proof-of-concept patch introduces a "smart" `J#` constructor > which constructs a `S#` instead if possible: > > {{{ > #!hs > -- | Demote 'J#' to 'S#' if possible. See also 'smartJ#'. > toSmall :: Integer -> Integer > toSmall i@(S# _) = i > toSmall (J# 0# _) = S# 0# > toSmall (J# 1# mb#) | isTrue# (v ># 0#) = S# v > where > v = indexIntArray# mb# 0# > toSmall (J# -1# mb#) | isTrue# (v <# 0#) = S# v > where > v = negateInt# (indexIntArray# mb# 0#) > toSmall i = i > > -- | Smart 'J#' constructor which tries to construct 'S#' if possible > smartJ# :: Int# -> ByteArray# -> Integer > smartJ# s# mb# = toSmall (J# s# mb#) > }}} > > And replaces a couple of `J#`-constructions which are likely to produce a > `S#`-fitting `Integer`. A `nofib` comparison for vanilla GHC HEAD vs > patched GHC HEAD is attached for further discussion. New description: In the course of a recent [[http://www.reddit.com/r/haskell/comments/1twtvm/the_problem_with_integer/|recent reddit discussion]] it was highlighted, that `integer-gmp` doesn't try to demote `J#` result-values to the more efficient `S#` even though they would fit into a machine word. The attached proof-of-concept patch introduces a "smart" `J#` constructor which constructs a `S#` value instead (if possible): {{{ #!hs -- | Demote 'J#' to 'S#' if possible. See also 'smartJ#'. toSmall :: Integer -> Integer toSmall i@(S# _) = i toSmall (J# 0# _) = S# 0# toSmall (J# 1# mb#) | isTrue# (v ># 0#) = S# v where v = indexIntArray# mb# 0# toSmall (J# -1# mb#) | isTrue# (v <# 0#) = S# v where v = negateInt# (indexIntArray# mb# 0#) toSmall i = i -- | Smart 'J#' constructor which tries to construct 'S#' if possible smartJ# :: Int# -> ByteArray# -> Integer smartJ# s# mb# = toSmall (J# s# mb#) }}} The patch replaces a couple of `J#`-invocations which are likely to produce a `S#`-fitting `Integer`. A `nofib` comparison for vanilla GHC HEAD vs. patched GHC HEAD is attached for further discussion. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 30 15:14:32 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Dec 2013 15:14:32 -0000 Subject: [GHC] #8638: Optimize by demoting "denormalized" Integers (i.e. J# -> S#) In-Reply-To: <042.e2b4c372649ba443c83acd6104d8dbd7@haskell.org> References: <042.e2b4c372649ba443c83acd6104d8dbd7@haskell.org> Message-ID: <057.c675915da5df6d5f8615284773660365@haskell.org> #8638: Optimize by demoting "denormalized" Integers (i.e. J# -> S#) --------------------------------------------+------------------------------ Reporter: hvr | Owner: hvr Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.7 Resolution: | Keywords: integer- Operating System: Unknown/Multiple | gmp Type of failure: Runtime performance bug | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by hvr): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 30 15:17:52 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Dec 2013 15:17:52 -0000 Subject: [GHC] #8638: Optimize by demoting "denormalized" Integers (i.e. J# -> S#) In-Reply-To: <042.e2b4c372649ba443c83acd6104d8dbd7@haskell.org> References: <042.e2b4c372649ba443c83acd6104d8dbd7@haskell.org> Message-ID: <057.8305c551f81cc92429e422b8fa78a238@haskell.org> #8638: Optimize by demoting "denormalized" Integers (i.e. J# -> S#) --------------------------------------------+------------------------------ Reporter: hvr | Owner: hvr Type: feature request | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.7 Resolution: | Keywords: integer- Operating System: Unknown/Multiple | gmp Type of failure: Runtime performance bug | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by simonpj): * status: patch => infoneeded Comment: Interesting. In general it seems like a good idea. Although making the test has a cost, if you get a win, it's a big win. I'd first like to know why `mandel` started allocating nearly 50% more store. (I use `-ticky` for answering this kind of question.) Maybe investigating that will show how the patch can be improved further. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 30 15:34:59 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Dec 2013 15:34:59 -0000 Subject: [GHC] #8624: -ddump-splices-file In-Reply-To: <048.f5eead94409241401357105f8bb65a4f@haskell.org> References: <048.f5eead94409241401357105f8bb65a4f@haskell.org> Message-ID: <063.7cfd03c0a3f21d99c82e2d960b434be3@haskell.org> #8624: -ddump-splices-file -------------------------------------+------------------------------------ Reporter: GregWeber | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by GregWeber): Thanks for the additional pointers! I am volunteering to do it, but won't be able to start until next week. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 30 16:05:00 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Dec 2013 16:05:00 -0000 Subject: [GHC] #8599: Deriving in associated data families ignores instance's constraints In-Reply-To: <047.15721e4f15b895eba1da55bf5a43686a@haskell.org> References: <047.15721e4f15b895eba1da55bf5a43686a@haskell.org> Message-ID: <062.bc470b4ce9b21478cbfe08ab528489da@haskell.org> #8599: Deriving in associated data families ignores instance's constraints -------------------------------------+------------------------------------ Reporter: mojojojo | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * owner: => goldfire Comment: I agree with Richard here. The primary goal of allowing you to declare a `type`/`data` family within a `class` declaration is to make the link explicit and to remind you if you forget to give the instance in an `instance` declaration of the class. I also love the duality: * in a class declaration you give the type signature for any value methods; in the instance you give the actual method. * in a class declaration you give the kind signature for any associated types; in the instance you give the actual type definitions. But really it's not much more than syntactic sugar. You could equally well give the associated type family definitions outside the class, and likewise the instances. However, as syntactic sugar goes, it's pretty heavy. GHC has a lot of code that deals with associated types! In any case, that's why I agree with Richard's analysis. I think it'd be a mistake to conflate the context for the class instance declaration with the context for a derived equality instance. Do clarify the documentation, thank you Richard. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 30 16:05:18 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Dec 2013 16:05:18 -0000 Subject: [GHC] #8607: Invalid location reported for type constructors In-Reply-To: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> References: <044.1d02fc535639300bc165507f0ca0b37a@haskell.org> Message-ID: <059.3a26b7301f9b88bf8fedea5f7407a72f@haskell.org> #8607: Invalid location reported for type constructors -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): I like it, thank you. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 30 17:59:52 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Dec 2013 17:59:52 -0000 Subject: [GHC] #8639: GHC API `runStmt` overrides qualified import of `it` variable Message-ID: <049.be8dc837cf02d09e814c29b69ace92a5@haskell.org> #8639: GHC API `runStmt` overrides qualified import of `it` variable ------------------------------------+------------------------------------- Reporter: agibiansky | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The `runStmt` function in `InteractiveEval` creates an `it` variable storing the last result. However, this variable somehow shadows qualified variables with the name `it`. For instance, importing Test.Hspec, running any statement, and then trying to use Test.Hspec.it (qualified) results in an "out of scope" error. The following small program demonstrates this: {{{ import GHC import GhcMonad import Outputable import GHC.Paths main = runGhc (Just libdir) $ do flags <- getSessionDynFlags setSessionDynFlags (flags{ hscTarget = HscInterpreted, ghcLink = LinkInMemory}) imps <- mapM parseImportDecl ["import Prelude", "import Test.Hspec"] setContext (map IIDecl imps) -- With the next line, you get an "Not in scope" exception. -- If you comment out this runStmt, it runs without error and prints the type. runStmt "3" RunToCompletion exprType "Test.Hspec.it" >>= (liftIO . putStrLn . showPpr flags) }}} GHCi somehow avoids this, but I have no idea how and could not figure it out from the sources. What's going on? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 30 18:20:23 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Dec 2013 18:20:23 -0000 Subject: [GHC] #4210: LLVM: Dynamic Library Support In-Reply-To: <045.9da2e8588befc1a62c55be781a6ff87b@haskell.org> References: <045.9da2e8588befc1a62c55be781a6ff87b@haskell.org> Message-ID: <060.596daeffff12038a7b3afaaf301e4811@haskell.org> #4210: LLVM: Dynamic Library Support -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: patch Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by bgamari): That is correct. Using `@object` prevents the linker from sending calls through the PLT. However, it would be nice to hear Simon confirm that his fears surrounding the efficiency of intra-package calls have been addressed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 30 19:26:22 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Dec 2013 19:26:22 -0000 Subject: [GHC] #8638: Optimize by demoting "denormalized" Integers (i.e. J# -> S#) In-Reply-To: <042.e2b4c372649ba443c83acd6104d8dbd7@haskell.org> References: <042.e2b4c372649ba443c83acd6104d8dbd7@haskell.org> Message-ID: <057.51a6fb8d6408068596f68fb534c025ce@haskell.org> #8638: Optimize by demoting "denormalized" Integers (i.e. J# -> S#) --------------------------------------------+------------------------------ Reporter: hvr | Owner: hvr Type: feature request | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.7 Resolution: | Keywords: integer- Operating System: Unknown/Multiple | gmp Type of failure: Runtime performance bug | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by hvr): Replying to [comment:3 simonpj]: > I'd first like to know why `mandel` started allocating nearly 50% more store. (I use `-ticky` for answering this kind of question.) Maybe investigating that will show how the patch can be improved further. I'm not sure yet why `mandel` allocates more as I couldn't see find any significant use of `Integer`s in the implementation. After some profiling I found out that swapping out the implementation of `magnitude` inside `Mandel.diverge` with a more naive one had a ''huge'' effect on the allocation. Now the report reads: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- ... maillist +0.0% +0.0% 0.04 0.04 +2.2% mandel -0.2% -45.4% 0.02 0.02 +0.0% mandel2 +0.0% +0.0% 0.00 0.00 +0.0% ... -------------------------------------------------------------------------------- Min -0.2% -45.4% -32.3% -32.3% -20.0% Max +0.1% +7.2% +1.6% +1.6% +23.1% Geometric Mean +0.1% -1.3% -1.7% -1.8% +0.0% }}} The modification I made was simply {{{ #!diff diff --git a/spectral/mandel/Mandel.lhs b/spectral/mandel/Mandel.lhs index 3f460ce..cc601f5 100644 --- a/spectral/mandel/Mandel.lhs +++ b/spectral/mandel/Mandel.lhs @@ -109,6 +109,8 @@ is the prelude function that calculates the euclidean norm diverge::Complex Double -> Double -> Bool diverge cmplx radius = magnitude cmplx > radius + where + magnitude (x :+ y) = sqrt (x*x + y*y) \end{code} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 30 19:51:23 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Dec 2013 19:51:23 -0000 Subject: [GHC] #8640: :show imports ignores -XNoImplicitPrelude Message-ID: <047.522405561fb51568dff539b89e1aa78b@haskell.org> #8640: :show imports ignores -XNoImplicitPrelude ------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The implicit import should not be shown: {{{ $ ghci -XNoImplicitPrelude ... > :show imports import Prelude -- implicit }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 30 20:12:55 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Dec 2013 20:12:55 -0000 Subject: [GHC] #8638: Optimize by demoting "denormalized" Integers (i.e. J# -> S#) In-Reply-To: <042.e2b4c372649ba443c83acd6104d8dbd7@haskell.org> References: <042.e2b4c372649ba443c83acd6104d8dbd7@haskell.org> Message-ID: <057.1d6bbfa280106e5978b9923379a1932e@haskell.org> #8638: Optimize by demoting "denormalized" Integers (i.e. J# -> S#) --------------------------------------------+------------------------------ Reporter: hvr | Owner: hvr Type: feature request | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.7 Resolution: | Keywords: integer- Operating System: Unknown/Multiple | gmp Type of failure: Runtime performance bug | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by hvr): Replying to [comment:4 hvr]: > I'm not sure yet why `mandel` allocates more as I couldn't see find any significant use of `Integer`s in the implementation. After some profiling I found out that swapping out the implementation of `magnitude` inside `Mandel.diverge` with a more naive one had a ''huge'' effect on the allocation. Ok, found the culprit; `magnitude` uses `scaleFloat` which in turn uses `decodeFloat`/`encodeFloat`. I removed the `smartJ#` I put into `decodeFloat` and the allocation-delta for the `mandel`-benchmark went back to more or less 0. As the main purpose of `decodeFloat` seems to be to be used in combination with `encodeFloat` I guess there's actually little benefit trying to demote the significant to `S#` anyway... I'll attach the new nofib report shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 30 20:13:25 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Dec 2013 20:13:25 -0000 Subject: [GHC] #8638: Optimize by demoting "denormalized" Integers (i.e. J# -> S#) In-Reply-To: <042.e2b4c372649ba443c83acd6104d8dbd7@haskell.org> References: <042.e2b4c372649ba443c83acd6104d8dbd7@haskell.org> Message-ID: <057.e7e23a5d357493c057f7f244e45212ea@haskell.org> #8638: Optimize by demoting "denormalized" Integers (i.e. J# -> S#) --------------------------------------------+------------------------------ Reporter: hvr | Owner: hvr Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.7 Resolution: | Keywords: integer- Operating System: Unknown/Multiple | gmp Type of failure: Runtime performance bug | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by hvr): * status: infoneeded => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 30 20:39:23 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Dec 2013 20:39:23 -0000 Subject: [GHC] #8603: GHC crashes on some code using StateT monad transformer In-Reply-To: <049.faef5c68395d742a3684db2c63ac8cd1@haskell.org> References: <049.faef5c68395d742a3684db2c63ac8cd1@haskell.org> Message-ID: <064.cca251ddc40b1daf8aa0253e8648a99e@haskell.org> #8603: GHC crashes on some code using StateT monad transformer ------------------------------------------------+-------------------------- Reporter: person1729 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time crash | (amd64) Test Case: typecheck/should_fail/T8603 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by monoidal): I don't understand completely what's going on here, but in your program `lift uniform [1,2,3]` should be `lift (uniform [1,2,3])`. This makes it compile under GHC 7.6. (I thought this error had long already been fixed in 7.7. Strange.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 30 21:01:37 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Dec 2013 21:01:37 -0000 Subject: [GHC] #8641: ghc with -odir and -prof cannot create the specified output directory Message-ID: <048.2d7f3fd6d82dfa87e6a726166d2648da@haskell.org> #8641: ghc with -odir and -prof cannot create the specified output directory -----------------------------------+--------------------------------------- Reporter: wmarshall | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- Calling ghc with -odir set to a non-existent directory causes ghc to create the directory. However, if the -prof option is also specified, ghc fails to create the directory and quits with an error. Steps to reproduce: {{{ $ echo 'main = print "Hello world"' > Main.hs $ ghc Main.hs -odir bin [1 of 1] Compiling Main ( Main.hs, bin\Main.o ) Linking Main.exe ... $ rm -Rvf bin removed `bin/Main.o' removed directory: `bin' $ ghc Main.hs -odir bin -prof [1 of 1] Compiling Main ( Main.hs, bin\Main.o ) C:/Program Files (x86)/Haskell Platform/2013.2.0.0/mingw/bin/ld.exe: cannot open output file bin\Main.o: No such file or directory collect2: ld returned 1 exit status }}} Expected result: The output directory is created regardless of whether -prof is specified. The above commands were executed from within Cygwin, but the error occurs in the Windows command shell as well. (I used Cygwin here because it is easier to give precise instructions to reproduce the error.) I have only tested this on Windows. I do not know if the issue exists on Linux or other platforms. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 30 22:47:54 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Dec 2013 22:47:54 -0000 Subject: [GHC] #8642: Allow GHCi to print non-pretty forms of things. Message-ID: <047.ccc9b115bdd88e90ed55051a25f1a4ce@haskell.org> #8642: Allow GHCi to print non-pretty forms of things. ------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Currently when we ask GHCi for :info or :type of something, it will do things like splitting over multiple lines and all that eye candy that people like to see. This however makes it more difficult for people to write text editor plugins &c that rely on GHCi output. Currently one has to write parsers to stitch the GHCi output back together which is fairly error prone and not really future-proof. Is there any chance for a more machine-friendly output? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 30 23:19:24 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Dec 2013 23:19:24 -0000 Subject: [GHC] #8642: Allow GHCi to print non-pretty forms of things. In-Reply-To: <047.ccc9b115bdd88e90ed55051a25f1a4ce@haskell.org> References: <047.ccc9b115bdd88e90ed55051a25f1a4ce@haskell.org> Message-ID: <062.4f87b5c3fe08e47cd5833c8576ff0c00@haskell.org> #8642: Allow GHCi to print non-pretty forms of things. -------------------------------------+------------------------------------ Reporter: Fuuzetsu | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Shoudn?t you use the GHC API then? Parsing output meant for human consumption has a certain smell of abuse. It would be great if one can run arbitrary `GhciMonad` actions from the interpreter prompt. Dennis Felsing has started some work in that direction, see http://www.haskell.org/pipermail/glasgow-haskell- users/2012-December/023161.html for pointers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 30 23:29:41 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Dec 2013 23:29:41 -0000 Subject: [GHC] #8642: Allow GHCi to print non-pretty forms of things. In-Reply-To: <047.ccc9b115bdd88e90ed55051a25f1a4ce@haskell.org> References: <047.ccc9b115bdd88e90ed55051a25f1a4ce@haskell.org> Message-ID: <062.f92283fdac361a8bd5cf1079c9898c67@haskell.org> #8642: Allow GHCi to print non-pretty forms of things. -------------------------------------+------------------------------------ Reporter: Fuuzetsu | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by hvr): Btw, line-breaking of compiler message can be suppressed somewhat by using `-dppr-cols999`, however that doesn't seem to apply to the pretty-printing of `:info` or `:type`. However, the major parsing/interaction issue I have encountered while working on the Emacs integration is the shared I/O on stdin/stdout between GHCi's and the interpreted/evaluated code output (interleaved output on STDOUT, as well as code trying to read from STDIN). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 31 02:38:25 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Dec 2013 02:38:25 -0000 Subject: [GHC] #8642: Allow GHCi to print non-pretty forms of things. In-Reply-To: <047.ccc9b115bdd88e90ed55051a25f1a4ce@haskell.org> References: <047.ccc9b115bdd88e90ed55051a25f1a4ce@haskell.org> Message-ID: <062.f2e11494721948451d932647fc8626c2@haskell.org> #8642: Allow GHCi to print non-pretty forms of things. -------------------------------------+------------------------------------ Reporter: Fuuzetsu | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Fuuzetsu): nomeata: Yes, perhaps, but it's often difficult to do so from an environment that doesn't have the ability to use Haskell libs, like most editors don't. Even ghc-mod spits out the type information in this pretty format. It's also a bit more difficult to wrestle with GHC API rather than just sending ?:i? to already running and loaded GHCi. If you feel that this is not something GHCi should do then by all means, please close the ticket! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 31 02:48:38 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Dec 2013 02:48:38 -0000 Subject: [GHC] #8301: error BaseReg must be in a register for THREADED_RTS In-Reply-To: <044.0651fb01dd71f2601e90f46aa455c558@haskell.org> References: <044.0651fb01dd71f2601e90f46aa455c558@haskell.org> Message-ID: <059.5faa6b2b40b8cd2d1ce4b6f7b85c0228@haskell.org> #8301: error BaseReg must be in a register for THREADED_RTS ----------------------------------------+----------------------------- Reporter: erikd | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Changes (by Khaelid): * cc: mjk3979@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 31 05:24:47 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Dec 2013 05:24:47 -0000 Subject: [GHC] #8643: Silent name shadowing Message-ID: <044.8dd660a5555a309c811cd8326c7ebc8b@haskell.org> #8643: Silent name shadowing ------------------------------------+------------------------------------- Reporter: mirpa | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5288 | ------------------------------------+------------------------------------- I have code like: {{{ let baseTex = (getTexPropNode nodes . NC.properties . NC.av $ geometry) >>= baseTex >>= (flip Map.lookup texs) . NC.tdSource }}} which gives me error: {{{ Games/secunda/Graph.hs:224:23: Couldn't match expected type `TexProperty -> Maybe a0' with actual type `Maybe b0' In the second argument of `(>>=)', namely `baseTex' In the first argument of `(>>=)', namely `(getTexPropNode nodes . NC.properties . NC.av $ geometry) >>= baseTex' In the expression: (getTexPropNode nodes . NC.properties . NC.av $ geometry) >>= baseTex >>= (flip Map.lookup texs) . NC.tdSource }}} However if I try to get type of expressin on the right hand side of {{{let baseTex = ...}}} in ghci then I get no error. Problem is that I am importing module with function {{{baseTex :: TexProperty -> Maybe TexDesc}}} and that function is shadowed by {{{let}}} expression which should have type of {{{Maybe Texture}}}. I tried to use {{{ghc-options: -Wall -fwarn-name-shadowing}}} in Cabal with no effect. From above error I conclude, that I made a type error. So I try to get type of expression in ghci which results in correct type - that makes my confusion. While I am trying to concentrate on type error, I am missing that I shadowed function by variable. This is not for the first time I've done same mistake. I would appreciate to get warnings about name shadowing since they makes me belief that I am using names of different type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 31 08:03:22 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Dec 2013 08:03:22 -0000 Subject: [GHC] #8603: GHC crashes on some code using StateT monad transformer In-Reply-To: <049.faef5c68395d742a3684db2c63ac8cd1@haskell.org> References: <049.faef5c68395d742a3684db2c63ac8cd1@haskell.org> Message-ID: <064.cb2789868b6ede112b4a16ba3e6858d2@haskell.org> #8603: GHC crashes on some code using StateT monad transformer ------------------------------------------------+-------------------------- Reporter: person1729 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time crash | (amd64) Test Case: typecheck/should_fail/T8603 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by simonpj): The point is that a type-incorrect program made GHC crash. That shouldn't happen, and that's what I fixed. Making the program itself right is another matter, as you point out. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 31 08:11:36 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Dec 2013 08:11:36 -0000 Subject: [GHC] #8643: Silent name shadowing In-Reply-To: <044.8dd660a5555a309c811cd8326c7ebc8b@haskell.org> References: <044.8dd660a5555a309c811cd8326c7ebc8b@haskell.org> Message-ID: <059.9d5f762c00acf061846b1e38fdc17820@haskell.org> #8643: Silent name shadowing -------------------------------------+------------------------------------ Reporter: mirpa | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #5288 -------------------------------------+------------------------------------ Comment (by simonpj): I'm afraid I don't understand your explanation. Are you saying that compiling the original module with `baseTex` in it should have given a name-shadowing error? Or what? Can you perhaps give a reproducible test case (ie not relying on other modules I don't have) and the sequence of steps that shows the problem? Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 31 08:23:28 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Dec 2013 08:23:28 -0000 Subject: [GHC] #8638: Optimize by demoting "denormalized" Integers (i.e. J# -> S#) In-Reply-To: <042.e2b4c372649ba443c83acd6104d8dbd7@haskell.org> References: <042.e2b4c372649ba443c83acd6104d8dbd7@haskell.org> Message-ID: <057.fc8bf4626dc316fc5c67c63df59d757f@haskell.org> #8638: Optimize by demoting "denormalized" Integers (i.e. J# -> S#) --------------------------------------------+------------------------------ Reporter: hvr | Owner: hvr Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.7 Resolution: | Keywords: integer- Operating System: Unknown/Multiple | gmp Type of failure: Runtime performance bug | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): Great. Now, what's happening in `symalg` and `kahan` (+4.7 and 6.7% resp)? Working on these small deltas seems tiresome, but what is a small delta in one program can be a massive one in another. It's not that we must have uniform improvement; just that we like to know ''why'' something gets worse, and deem it an acceptable compromise. What is puzzling to me is that I don't think `smartJ#` does ''any'' allocation (apart from its result) so I don't see why allocation should ever increase. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 31 08:23:34 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Dec 2013 08:23:34 -0000 Subject: [GHC] #8638: Optimize by demoting "denormalized" Integers (i.e. J# -> S#) In-Reply-To: <042.e2b4c372649ba443c83acd6104d8dbd7@haskell.org> References: <042.e2b4c372649ba443c83acd6104d8dbd7@haskell.org> Message-ID: <057.3740fb838df32dc629d788a47c6c98d1@haskell.org> #8638: Optimize by demoting "denormalized" Integers (i.e. J# -> S#) --------------------------------------------+------------------------------ Reporter: hvr | Owner: hvr Type: feature request | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.7 Resolution: | Keywords: integer- Operating System: Unknown/Multiple | gmp Type of failure: Runtime performance bug | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by simonpj): * status: patch => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 31 10:02:13 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Dec 2013 10:02:13 -0000 Subject: [GHC] #8603: GHC crashes on some code using StateT monad transformer In-Reply-To: <049.faef5c68395d742a3684db2c63ac8cd1@haskell.org> References: <049.faef5c68395d742a3684db2c63ac8cd1@haskell.org> Message-ID: <064.fb18281ca91e02049819c72f83a52298@haskell.org> #8603: GHC crashes on some code using StateT monad transformer ------------------------------------------------+-------------------------- Reporter: person1729 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time crash | (amd64) Test Case: typecheck/should_fail/T8603 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by monoidal): What confuses me is that before the commit 7.7 already did not crash for this program. I checked that a6f6169a9939525c859b274955e8606d6080100f (commit just before yours) and HEAD give the same error message. Was the commit just internal refactoring, or has it visible consequences? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 31 10:12:07 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Dec 2013 10:12:07 -0000 Subject: [GHC] #8603: GHC crashes on some code using StateT monad transformer In-Reply-To: <049.faef5c68395d742a3684db2c63ac8cd1@haskell.org> References: <049.faef5c68395d742a3684db2c63ac8cd1@haskell.org> Message-ID: <064.e26a46648928b86f6924d35d3ded8403@haskell.org> #8603: GHC crashes on some code using StateT monad transformer ------------------------------------------------+-------------------------- Reporter: person1729 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time crash | (amd64) Test Case: typecheck/should_fail/T8603 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by simonpj): Well that is puzzling. I was sure I saw HEAD crash with `kindFunResult` panic. Anyway, regardless the refactoring is a good thing, I think. There really was a bug before. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 31 10:42:13 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Dec 2013 10:42:13 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.b1ecae36a8c1fa511b5b3567e115a858@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------ Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 5877 -------------------------------------+------------------------------------ Changes (by akio): * cc: tkn.akio@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 31 14:20:58 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Dec 2013 14:20:58 -0000 Subject: [GHC] #8636: Infix declaration on operators ending on backslash In-Reply-To: <049.f087d7cb3e1ecaa0bf93cea006d4da7c@haskell.org> References: <049.f087d7cb3e1ecaa0bf93cea006d4da7c@haskell.org> Message-ID: <064.bc4471a6806b75d1ee8affac41f129fc@haskell.org> #8636: Infix declaration on operators ending on backslash ----------------------------------------------+---------------------------- Reporter: jcristovao | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects valid program | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by monoidal): Are you sure? I cannot reproduce the difference in behavior between 7.6 and 7.7. This escaping happens with `-XCPP` flag but it does not seem to be version dependent. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 31 14:23:49 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Dec 2013 14:23:49 -0000 Subject: [GHC] #8643: Silent name shadowing In-Reply-To: <044.8dd660a5555a309c811cd8326c7ebc8b@haskell.org> References: <044.8dd660a5555a309c811cd8326c7ebc8b@haskell.org> Message-ID: <059.ce34d1275cc2920637c783e90f711290@haskell.org> #8643: Silent name shadowing -------------------------------------+------------------------------------ Reporter: mirpa | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #5288 -------------------------------------+------------------------------------ Comment (by mirpa): {{{ $ ghc -Wall -fwarn-name-shadowing --make main.hs [2 of 2] Compiling Main ( main.hs, main.o ) main.hs:9:23: Couldn't match expected type `Int -> Maybe a0' with actual type `Maybe b0' In the second argument of `(>>=)', namely `foo' In the first argument of `(>>=)', namely `bar 1 >>= foo' In the expression: bar 1 >>= foo >>= return . (+ 1) $ ghc -Wall -fwarn-name-shadowing --make main2.hs [2 of 2] Compiling Main ( main2.hs, main2.o ) main2.hs:8:1: Warning: Top-level binding with no type signature: main :: IO () main2.hs:9:7: Warning: This binding for `foo' shadows the existing binding imported from `FooLib' at main2.hs:3:1-19 Linking main2 ... }}} Compiling {{{main.hs}}} gives no warning about shadowing of {{{foo}}}. I must use qualified name first in order to get warning about shadowing as shown in {{{main2.hs}}}. I would like to have name shadowing warning when compiling {{{main.hs}}} (while I don't see it necessary in case of {{{main2.hs}}}). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 31 15:13:01 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Dec 2013 15:13:01 -0000 Subject: [GHC] #8609: Clean up block allocator In-Reply-To: <045.da9b454c1e9861c91a9a3c65db94c556@haskell.org> References: <045.da9b454c1e9861c91a9a3c65db94c556@haskell.org> Message-ID: <060.9b294e42ca121f2f6078b5a3ee1219b0@haskell.org> #8609: Clean up block allocator -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: patch Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Easy (less than 1 performance bug | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"38d17a0cdfee64cc73537e7bb96eb2f25df9ec92/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="38d17a0cdfee64cc73537e7bb96eb2f25df9ec92" Clean up block allocator, fixes #8609 Signed-off-by: Edward Z. Yang }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 31 15:17:55 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Dec 2013 15:17:55 -0000 Subject: [GHC] #8609: Clean up block allocator In-Reply-To: <045.da9b454c1e9861c91a9a3c65db94c556@haskell.org> References: <045.da9b454c1e9861c91a9a3c65db94c556@haskell.org> Message-ID: <060.9ddca1e524f3e2696f54614669a14a26@haskell.org> #8609: Clean up block allocator -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: low | Milestone: Component: Runtime System | Version: 7.7 Resolution: fixed | Keywords: patch Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Easy (less than 1 performance bug | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 31 15:26:14 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Dec 2013 15:26:14 -0000 Subject: [GHC] #8641: ghc with -odir and -prof does not create the specified output directory (was: ghc with -odir and -prof cannot create the specified output directory) In-Reply-To: <048.2d7f3fd6d82dfa87e6a726166d2648da@haskell.org> References: <048.2d7f3fd6d82dfa87e6a726166d2648da@haskell.org> Message-ID: <063.a6484daa1eb5290e2e0098a8954c6436@haskell.org> #8641: ghc with -odir and -prof does not create the specified output directory ---------------------------------------+----------------------------------- Reporter: wmarshall | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 31 17:57:08 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Dec 2013 17:57:08 -0000 Subject: [GHC] #8639: GHC API `runStmt` overrides qualified import of `it` variable In-Reply-To: <049.be8dc837cf02d09e814c29b69ace92a5@haskell.org> References: <049.be8dc837cf02d09e814c29b69ace92a5@haskell.org> Message-ID: <064.b98ce73bf623061a108f2a05c4d2b1d7@haskell.org> #8639: GHC API `runStmt` overrides qualified import of `it` variable -------------------------------------+------------------------------------ Reporter: agibiansky | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Good point. I'll fix this. I think you missed out some code in the test: {{{ setSessionDynFlags (flags{ hscTarget = HscInterpreted, ghcLink = LinkInMemory}) * target <- guessTarget "Test/Hspec.hs" Nothing * setTargets [target] * load LoadAllTargets imps <- mapM parseImportDecl ["import Prelude", "import Test.Hspec"] }}} The lines marked * are important! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 31 18:58:57 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Dec 2013 18:58:57 -0000 Subject: [GHC] #8639: GHC API `runStmt` overrides qualified import of `it` variable In-Reply-To: <049.be8dc837cf02d09e814c29b69ace92a5@haskell.org> References: <049.be8dc837cf02d09e814c29b69ace92a5@haskell.org> Message-ID: <064.ceefe7ce0308aa22cb9556fce9054a60@haskell.org> #8639: GHC API `runStmt` overrides qualified import of `it` variable -------------------------------------+------------------------------------ Reporter: agibiansky | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by agibiansky): Simon, I'm not sure if this is relevant to the bug, but just FYI, the program I posted was complete. I did not have `Hspec.hs` as a target, I simply had the `hspec` package installed via `cabal install` (as a user normally would.) I just verified to make sure - if you copy and paste the entire program and compile with ghc 7.6.3, everything works (or doesn't work) as reported. Thanks for tackling this! -- Andrew -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 31 22:13:12 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Dec 2013 22:13:12 -0000 Subject: [GHC] #8644: 'Untouchable' error with constraint variable in rank-2 type Message-ID: <047.3b0cdf413c3f987fdab206c0248d0b2b@haskell.org> #8644: 'Untouchable' error with constraint variable in rank-2 type -------------------------------------+------------------------------------- Reporter: sbarclay | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: Unknown/Multiple | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- The following program compiles fine with GHC 7.6.3: {{{#!haskell {-# LANGUAGE ConstraintKinds, RankNTypes, GADTs #-} data Dict c where Dict :: c => Dict c foo :: Dict c -> (c => r) -> r foo Dict x = x bar :: Dict () bar = Dict main :: IO () main = print $ foo bar "Hello" }}} However, it produces the following error with HEAD: {{{ ConstraintIssue.hs:12:8: No instance for (Show s0) arising from a use of ?print? The type variable ?s0? is ambiguous Note: there are several potential instances: instance Show Double -- Defined in ?GHC.Float? instance Show Float -- Defined in ?GHC.Float? instance (Integral a, Show a) => Show (GHC.Real.Ratio a) -- Defined in ?GHC.Real? ...plus 24 others In the expression: print In the expression: print $ foo bar "Hello" In an equation for ?main?: main = print $ foo bar "Hello" ConstraintIssue.hs:12:24: Couldn't match expected type ?s0? with actual type ?[Char]? ?s0? is untouchable inside the constraints (()) bound by a type expected by the context: (()) => s0 at ConstraintIssue.hs:12:16-30 In the second argument of ?foo?, namely ?"Hello"? In the second argument of ?($)?, namely ?foo bar "Hello"? In the expression: print $ foo bar "Hello" }}} If the type signature of 'main' is removed, the code compiles OK. If the empty constraint () is replaced with an equality constraint such as Int ~ Int, then the above error occurs with both 7.6.3 and HEAD, which I guess is intended behaviour. -- Ticket URL: GHC The Glasgow Haskell Compiler