From ghc-devs at haskell.org Sat Aug 1 00:06:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Aug 2015 00:06:42 -0000 Subject: [GHC] #10719: Malformed data type quotation accepted In-Reply-To: <048.6b945575ed583054da28b46717dca1a6@haskell.org> References: <048.6b945575ed583054da28b46717dca1a6@haskell.org> Message-ID: <063.70514e82b7595a7d1b6fe3cf4780dc35@haskell.org> #10719: Malformed data type quotation accepted -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by heisenbug): I should add that `:set -XDataKinds` and `:set -XTemplateHaskell` are on. I have played around a bit and these are actually accepted Prelude Language.Haskell.TH> {{{$(stringE . show =<< [d| type C = A; data A x where C :: 'C Int |])}}} "[TySynD C_1627404906 [] (ConT A_1627404904),DataD [] A_1627404904 [PlainTV x_1627404907] [ForallC [] [AppT (AppT EqualityT (VarT x_1627404907)) (ConT GHC.Types.Int)] (NormalC C_1627404905 [])] []]" Prelude Language.Haskell.TH> {{{$(stringE . show =<< [d| data A x where C :: 'C Int |])}}} "[DataD [] A_1627405048 [PlainTV x_1627405050] [ForallC [] [AppT (AppT EqualityT (VarT x_1627405050)) (ConT GHC.Types.Int)] (NormalC C_1627405049 [])] []]" with both `DataKinds` and `NoDataKinds`. All is very suspicipus, I think the result type's head is never checked. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 1 01:40:12 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Aug 2015 01:40:12 -0000 Subject: [GHC] #10720: New GHC fails to specialize imported function Message-ID: <045.bc4c23e626cc82190cc1366a8178cfbb@haskell.org> #10720: New GHC fails to specialize imported function -------------------------------------+------------------------------------- Reporter: wyager | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: MacOS X performance, inline, specialize | Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I just installed the new Haskell platform for OS X. It seems to have caused a major performance regression for a program I'm working on, making it well over 25x slower. The culprit appears to be that the new GHC (7.10.2) fails to specialize an imported function. If I manually add a SPECIALIZE pragma, performance goes back to around what it used to be. The code in question is located at https://github.com/wyager/HNet . As it stands, the code takes about 30 seconds to run on my machine. With the previous haskell-platform, it only took about .9 seconds. If I modify Operations.hs and uncomment the SPECIALIZE pragma, runtime goes down to about 1.1 seconds (still slower for some reason, but not awful). To test, compile with -O2 (as the program makes heavy use of Data.Vector, which requires -fspec-constr for performance). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 1 01:47:43 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Aug 2015 01:47:43 -0000 Subject: [GHC] #10721: GHC INLINE pragma behavior does not match docs Message-ID: <045.27a53624f8de5b0505a3ea87e28c8301@haskell.org> #10721: GHC INLINE pragma behavior does not match docs -------------------------------------+------------------------------------- Reporter: wyager | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: MacOS X specialize, inline, inlinable, | pragma | Architecture: x86_64 | Type of failure: Incorrect (amd64) | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Per https://downloads.haskell.org/~ghc/7.8.4/docs/html/users_guide/pragmas.html #specialize-pragma , I should be able to SPECIALIZE an imported function if the function is marked as INLINABLE at the definition site. While trying to debug a related issue (#10720), I tried making the original function `(??)` INLINABLE and then SPECIALIZing it at the call site. However, GHC tells me "`Warning: SPECIALISE pragma on INLINE function probably won't fire: ????`". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 1 01:48:23 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Aug 2015 01:48:23 -0000 Subject: [GHC] #10720: New GHC fails to specialize imported function In-Reply-To: <045.bc4c23e626cc82190cc1366a8178cfbb@haskell.org> References: <045.bc4c23e626cc82190cc1366a8178cfbb@haskell.org> Message-ID: <060.c1234b21fdcad1a5837ce73c15cecbe1@haskell.org> #10720: New GHC fails to specialize imported function -------------------------------------+------------------------------------- Reporter: wyager | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | performance, inline, specialize Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by wyager): Also see #10721 for a potentially related issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 1 02:32:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Aug 2015 02:32:36 -0000 Subject: [GHC] #5463: SPECIALISE pragmas generated from Template Haskell are ignored In-Reply-To: <052.5da0a08d27fdc8dd517b247a84e49319@haskell.org> References: <052.5da0a08d27fdc8dd517b247a84e49319@haskell.org> Message-ID: <067.0101e0693c36ba558266d1ef2439e4d2@haskell.org> #5463: SPECIALISE pragmas generated from Template Haskell are ignored -------------------------------------+------------------------------------- Reporter: NickSmallbone | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10047 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * related: => #10047 Comment: Ticket #10047 discusses the annoyance of GHC's current behavior around top-level splices. One possible conclusion to that ticket suggests that a top-level quasiquote would indeed be spliced in before type-checking any declarations. This means both that the `SPECIALISE` pragma would work but also that the name of the function to specialise would be out of scope. At least under this scenario, the location of the splice wouldn't matter. I still don't know what to suggest to really fix this, however. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 1 02:33:11 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Aug 2015 02:33:11 -0000 Subject: [GHC] #10047: inconsistency in name binding between splice and quasiquotation In-Reply-To: <047.467ed7feed46ef69006cfd30a0e1c7fb@haskell.org> References: <047.467ed7feed46ef69006cfd30a0e1c7fb@haskell.org> Message-ID: <062.f030bc007bf1761fbe8ac170e5c1b776@haskell.org> #10047: inconsistency in name binding between splice and quasiquotation -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T10047 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): See #5463 for another scenario where having flexibility around the issue discussed here would be helpful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 1 02:39:05 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Aug 2015 02:39:05 -0000 Subject: [GHC] #10719: Malformed data type quotation accepted In-Reply-To: <048.6b945575ed583054da28b46717dca1a6@haskell.org> References: <048.6b945575ed583054da28b46717dca1a6@haskell.org> Message-ID: <063.49526311333e9504f5a0e04ec531ce1d@haskell.org> #10719: Malformed data type quotation accepted -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * component: Compiler => Template Haskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 1 02:58:48 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Aug 2015 02:58:48 -0000 Subject: [GHC] #10722: GHC generates wrong unused type argument warning(ScopedTypeVariables related) Message-ID: <043.10dfce0f67b1d66985f02b8aa664359c@haskell.org> #10722: GHC generates wrong unused type argument warning(ScopedTypeVariables related) -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE KindSignatures, ScopedTypeVariables #-} {-# OPTIONS_GHC -Wall #-} module Main where import Data.Proxy class Blah (a :: * -> *) where f :: a b -> b instance forall b . Blah [] where f a = let (_ :: Proxy b) = undefined in head a main :: IO () main = return () }}} When I run this using GHC 7.10.1 and GHC HEAD, I'm getting this warnings: {{{ [1 of 1] Compiling Main ( Main.hs, Main.o ) Main.hs:12:17: warning: Unused quantified type variable ?b? In the type ?forall b. Blah []? In an instance declaration Main.hs:13:13: warning: This pattern-binding binds no variables: (_ :: Proxy b) = undefined Linking Main ... }}} First warning is wrong. `b` is used, and this program doesn't compile if I remove that `b`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 1 06:19:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Aug 2015 06:19:32 -0000 Subject: [GHC] #10723: Make declarations in signatures "weakly bound" until they are used Message-ID: <045.468e4f2d1d9f6be5dd513d2c8bb6c010@haskell.org> #10723: Make declarations in signatures "weakly bound" until they are used -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Priority: normal | Milestone: Component: Package | Version: 7.11 system | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Suppose you are the author of a library in a Backpack world, and you publish a signature package which defines the entire public facing interface of your library. The library `foo` which uses of your library decides to `include` the signature package for convenience, but actually only uses a small portion of the API. Later, you make a BC-breaking change in one part of the library and release a new signature package. The library `bar` which uses your library includes this NEW signature package, using a different portion of the API which was unaffected by the by the BC change. Now, a hapless user tries to use `foo` and `bar`, but Backpack complains that the requirements are not compatible. What's the problem here? The practice of writing reusable signature packages for people to use caused the requirements of `foo` and `bar` to become too large, since they included a lot of junk that these libraries didn't actually use. It would be far better if you could `include` a signature package, but only "require" the bits of it that you actually used! How can we achieve this? 1. We augment the `ModIface` of signature merges (#10690) to record whether or not a declaration was (transitively) used or not by some module. Used declarations must be filled, but unused ones are treated more flexibly: if they are merged with a different, incompatible but used requirement, they disappear, and we don't check if an implementing module actually implemented the declaration. (If two unused incompatible requirements are merged, we just erase the name.) 2. How do we compute the usage info? I think it will have to be done during shaping (which runs the renamer). We only need to annotate each declaration a signature with the transitive set of names from other signatures that it has used--this can be incrementally computed. (It's not necessary to annotate declarations in modules, since they are always assumed to use holes). Then whenever a declaration from a signature is used in a module, we mark its transitive set as used. This information can then be used later when constructing the merged `ModIface` which represents the "public requirement" of the package. So, for example, a package containing only signatures would contain all unused declarations (however, they may start being used by a package which includes them). Any unused declaration which isn't mixed with another incompatible declaration can be imported (causing it to be used), but we will complain if you try to use a name and we can't tell which declaration to use. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 1 10:00:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Aug 2015 10:00:33 -0000 Subject: [GHC] #10711: Defining mapM_ in terms of traverse_ causes substantial blow-up in ByteCodeAsm In-Reply-To: <046.926df7dc33b426cbfee9f2a989a5cdc6@haskell.org> References: <046.926df7dc33b426cbfee9f2a989a5cdc6@haskell.org> Message-ID: <061.d4ddaa03143cc36027648289c5174a55@haskell.org> #10711: Defining mapM_ in terms of traverse_ causes substantial blow-up in ByteCodeAsm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: ghcirun004 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by akio): I think the quadratic behavior comes from the fact that the `>>=` linearly traverses its LHS. Let's define the size of an `Assembler` value with: {{{#!hs size :: Assembler a -> Integer size (Pure _) = 1 size (Thing i k) = 1 + size (k i) }}} `m >>= f` performs `O(size(m))` operations because `>>=` is recursive on its LHS. Most of the cost is hidden inside a lambda, but you will have to pay it eventually, namely when `run` is finally applied. Now we can analyze the cost of other operations: * `m >> n` needs `O(size(m))` operations, because it's `m >>= \_ -> n`. * `f <$> m` needs `O(size(m))` operations, because it's `m >>= return . f`. * `m <*> n` needs `O(size(m) + size(n))` operations, because it's `m >>= \v -> n >>= \w -> return v w`. * `m *> n` needs `O(size(m) + size(n))` operations, because it's `const <$> m <*> n`. If you use `mapM_` with a `N`-element list of 2-sized `Assembler`s, each application of `>>` costs `O(1)`, so the total cost is `O(N)`. If you use `mapA_` instead, the LHS of an application of `*>` is `O(1)` large but the RHS is `O(N)` large on average. This means it needs `O(N)` operations on average, so the total cost is `O(N*N)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 1 11:04:59 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Aug 2015 11:04:59 -0000 Subject: [GHC] #9406: unexpected failure for T7837(profasm) In-Reply-To: <042.6cf0b0817037f8cfba5de5652e277f8a@haskell.org> References: <042.6cf0b0817037f8cfba5de5652e277f8a@haskell.org> Message-ID: <057.5cad9c82e6302835d1b86d82882bfa88@haskell.org> #9406: unexpected failure for T7837(profasm) -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: worksforme | Keywords: T7837 Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: T7837 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: This seems now fixed, `make TEST=T7837 WAY=prof TEST_HC=ghc-7.10.2` succeeds. For some reason ghc-7.8 and earlier were firing extra rules when compiled with `-prof -auto-all`. {{{ module T9406 where class (Fractional a) => Norm a where norm :: a -> a normalize :: (Norm a) => a -> a normalize x = x / norm x }}} {{{ $ ghc-7.8.4 -c T9406.hs -fforce-recomp -O -ddump-rule-firings -auto-all -prof Rule fired: Class op $p1Norm Rule fired: Class op norm Rule fired: Class op / $ ghc-7.8.4 -c T9406.hs -fforce-recomp -O -ddump-rule-firings $ ghc-7.10.2 -c T9406.hs -fforce-recomp -O -ddump-rule-firings -auto-all -prof $ ghc-7.10.2 -c T9406.hs -fforce-recomp -O -ddump-rule-firings }}} I'm not adding this as a test, since we have T7837 already. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 1 11:40:48 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Aug 2015 11:40:48 -0000 Subject: [GHC] #8721: Testsuite not reporting errors for DYN way on OS X In-Reply-To: <046.8af9e017e06f897fefadc3e624641754@haskell.org> References: <046.8af9e017e06f897fefadc3e624641754@haskell.org> Message-ID: <061.0eaee5bdf121bba531ceb513e0adcd2f@haskell.org> #8721: Testsuite not reporting errors for DYN way on OS X -------------------------------+------------------------------------------- Reporter: darchon | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 7.6.3 Resolution: fixed | Keywords: dynamic linking Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+------------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: > Seeing how as of 7.8 the testsuite and an installed GHC are "aligned", I guess the status of this ticket should be turned to either solved or wontfix? Ok, let's do so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 1 11:48:02 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Aug 2015 11:48:02 -0000 Subject: [GHC] #7273: Binary size increase in nofib/grep between 7.6.1 and HEAD In-Reply-To: <047.56a3d4f639e4f19c232c77ec82adbeca@haskell.org> References: <047.56a3d4f639e4f19c232c77ec82adbeca@haskell.org> Message-ID: <062.3c972ba5d38afebacacaa2f2a8cdcbca@haskell.org> #7273: Binary size increase in nofib/grep between 7.6.1 and HEAD -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 1 11:53:28 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Aug 2015 11:53:28 -0000 Subject: [GHC] #9848: List.all does not fuse In-Reply-To: <049.2f5a48f3cdf200c755c1a1e10fe7787f@haskell.org> References: <049.2f5a48f3cdf200c755c1a1e10fe7787f@haskell.org> Message-ID: <064.584966549673ca2c4a42a08cb9830e75@haskell.org> #9848: List.all does not fuse -------------------------------------+------------------------------------- Reporter: klapaucius | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by akio): * cc: akio (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 1 12:51:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Aug 2015 12:51:19 -0000 Subject: [GHC] #10159: cabal build/ghc compiler causes sudden hard reboot of my computer! In-Reply-To: <046.f6a8819131c1ac525f6581f5be865c05@haskell.org> References: <046.f6a8819131c1ac525f6581f5be865c05@haskell.org> Message-ID: <061.f1773a64e20115fcc92ce63729095dd0@haskell.org> #10159: cabal build/ghc compiler causes sudden hard reboot of my computer! ---------------------------------+----------------------------------------- Reporter: jamshid | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: worksforme | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => worksforme Comment: Replying to [comment:5 jamshid]: > First, why doesn't anything else trigger this, even when I rev up all my cores with processes running an empty loop.... I don't know, but regardless of what ghc does or doesn't do, your computer shouldn't just reboot itself. Try looking elsewhere for the cause of this problem, or workaround it by using `cabal build -jn`, where `n` is smaller than the number of cores you have. > and second, why does "cabal install" use 1 core, while "cabal build" uses many (by default). For me multiple cores are only used with either `cabal build -j` or `cabal install -j`, or when I set the jobs field in .cabal/cabal.config. If you still get different results, please open an issue with [https://github.com/haskell/cabal/issues cabal]. ghc by default doesn't use multiple cores. I'm closing this bug, as we won't make any progress on it, and there is a workaround. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 1 14:05:43 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Aug 2015 14:05:43 -0000 Subject: [GHC] #10722: GHC accepts "instance forall b. Blah []" (was: GHC generates wrong unused type argument warning(ScopedTypeVariables related)) In-Reply-To: <043.10dfce0f67b1d66985f02b8aa664359c@haskell.org> References: <043.10dfce0f67b1d66985f02b8aa664359c@haskell.org> Message-ID: <058.9fcaecf2a3227f5f9f1ebb1680621a3b@haskell.org> #10722: GHC accepts "instance forall b. Blah []" -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * failure: None/Unknown => GHC accepts invalid program Old description: > {{{#!hs > {-# LANGUAGE KindSignatures, ScopedTypeVariables #-} > > {-# OPTIONS_GHC -Wall #-} > > module Main where > > import Data.Proxy > > class Blah (a :: * -> *) where > f :: a b -> b > > instance forall b . Blah [] where > f a = let (_ :: Proxy b) = undefined in head a > > main :: IO () > main = return () > }}} > > When I run this using GHC 7.10.1 and GHC HEAD, I'm getting this warnings: > > {{{ > [1 of 1] Compiling Main ( Main.hs, Main.o ) > > Main.hs:12:17: warning: > Unused quantified type variable ?b? > In the type ?forall b. Blah []? > In an instance declaration > > Main.hs:13:13: warning: > This pattern-binding binds no variables: (_ :: Proxy b) = undefined > Linking Main ... > }}} > > First warning is wrong. `b` is used, and this program doesn't compile if > I remove that `b`. New description: {{{#!hs {-# LANGUAGE KindSignatures, ScopedTypeVariables #-} {-# OPTIONS_GHC -Wall #-} module Main where import Data.Proxy class Blah (a :: * -> *) where f :: a b -> b instance forall b . Blah [] where f a = let (_ :: Proxy b) = undefined in head a main :: IO () main = return () }}} When I run this using GHC 7.10.1 and GHC HEAD, I'm getting this warnings: {{{ [1 of 1] Compiling Main ( Main.hs, Main.o ) Main.hs:12:17: warning: Unused quantified type variable ?b? In the type ?forall b. Blah []? In an instance declaration Main.hs:13:13: warning: This pattern-binding binds no variables: (_ :: Proxy b) = undefined Linking Main ... }}} but the program compiles successfully. -- Comment: Assuming you wanted to refer to the type variable `b` in the type of `f`, you should use InstanceSigs as described in section 7.6.3.6 of https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/type- class-extensions.html: {{{ instance Blah [] where f :: forall b. [b] -> b f a = let (_ :: Proxy b) = undefined in head a }}} `instance forall b . Blah []` is meaningless, and should be rejected. I edited the ticket description accordingly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 1 14:32:38 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Aug 2015 14:32:38 -0000 Subject: [GHC] #10549: floatExpr tick break<2> In-Reply-To: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> References: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> Message-ID: <066.41c9384b8eb1d1c472e60304ce318d39@haskell.org> #10549: floatExpr tick break<2> -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * priority: normal => high * version: 7.11 => 7.10.2 * milestone: => 7.10.3 Comment: Here is a test to reproduce the problem with ghci. {{{ {-# OPTIONS_GHC -O2 #-} module T10549 where import qualified Data.ByteString.Internal as Internal import System.IO.Unsafe (unsafePerformIO) import Data.Word (Word8) import Foreign.Ptr (Ptr) import Foreign.Storable (peek) type S = Ptr Word8 chr :: S -> Char chr x = Internal.w2c $ unsafePerformIO $ peek x }}} Running `ghc-7.10.1 --interactive T10549.hs` results in: {{{ GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help T10549.hs:1:16: Warning: -O conflicts with --interactive; -O ignored [1 of 1] Compiling T10549 ( T10549.hs, interpreted ) Ok, modules loaded: T10549. }}} Running `ghc-7.10.2 --interactive T10549.hs` results in: {{{ GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling T10549 ( T10549.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): floatExpr tick break<3>() }}} So somehow the `OPTIONS_GHC -O2` in the file doesn't get ignored (it does when given on the command line). To reproduce the problem with the Shake sources (version 0.15.4), run `ghci src/Development/Ninja/Lexer.hs -isrc`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 1 14:49:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Aug 2015 14:49:42 -0000 Subject: [GHC] #10719: Malformed data type quotation accepted In-Reply-To: <048.6b945575ed583054da28b46717dca1a6@haskell.org> References: <048.6b945575ed583054da28b46717dca1a6@haskell.org> Message-ID: <063.43cb4c5e80c66ce14e67a7549760b943@haskell.org> #10719: Malformed data type quotation accepted -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by heisenbug): Here is the rest of the diagnosis: {{{ compiler/deSugar/DsMeta.hs:626: | Just (_, tys) <- hsTyGetAppHead_maybe res_ty }}} Name if the constructor (or whatever) is ignored here. We should know whether it is a constructor/variable and and check against the GADT name (when constructor) otherwise issue an extra equality constraint. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 1 14:55:43 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Aug 2015 14:55:43 -0000 Subject: [GHC] #10722: GHC accepts "instance forall b. Blah []" In-Reply-To: <043.10dfce0f67b1d66985f02b8aa664359c@haskell.org> References: <043.10dfce0f67b1d66985f02b8aa664359c@haskell.org> Message-ID: <058.0c2c4431aa7c81b87de3d902186fc5ec@haskell.org> #10722: GHC accepts "instance forall b. Blah []" -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by osa1): Do you mean this syntax should be rejected by the parser? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 1 15:04:12 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Aug 2015 15:04:12 -0000 Subject: [GHC] #10722: GHC accepts "instance forall b. Blah []" In-Reply-To: <043.10dfce0f67b1d66985f02b8aa664359c@haskell.org> References: <043.10dfce0f67b1d66985f02b8aa664359c@haskell.org> Message-ID: <058.7deb2e2c2c957a95313a94160feb7d92@haskell.org> #10722: GHC accepts "instance forall b. Blah []" -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Well I don't care exactly how it is implemented, but logically it is a parse error yes. It is the same category of error as {{{ instance Int -> Blah [] where ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 1 15:30:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Aug 2015 15:30:39 -0000 Subject: [GHC] #10722: GHC accepts "instance forall b. Blah []" In-Reply-To: <043.10dfce0f67b1d66985f02b8aa664359c@haskell.org> References: <043.10dfce0f67b1d66985f02b8aa664359c@haskell.org> Message-ID: <058.af0b3a4468e4fc9f02155d54c54d714d@haskell.org> #10722: GHC accepts "instance forall b. Blah []" -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Actually I suppose you could view it as new syntax enabled by ScopedTypeVariables. It is harmless, but also useless (variables mentioned in the instance head are scoped over the instance body automatically, and variables not mentioned in the instance head will never be forced to be any particular type). I still tend to think the syntax should be invalid. I assume what's going on here is that the parser parses everything between `instance` and `where` as a "type", and then does some sanity checks to make sure the instance declaration isn't too ill-formed. But some stuff falls through the cracks here, like {{{ instance (Eq T) where ... -- should be rejected according to the Report, -- but is accepted by ghc }}} That one might not be worth fixing though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 1 15:33:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Aug 2015 15:33:22 -0000 Subject: [GHC] #10639: Tight (non-allocating) loop freezes the scheduler In-Reply-To: <048.3130b8c9dae40d4cc95f52d78c185152@haskell.org> References: <048.3130b8c9dae40d4cc95f52d78c185152@haskell.org> Message-ID: <063.55a95274d3b8bb1e2fef2f62cbbe83ca@haskell.org> #10639: Tight (non-allocating) loop freezes the scheduler -------------------------------------+------------------------------------- Reporter: gizmo.mk0 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by gizmo.mk0): "It should be documented though. Would someone feel able to add a bullet to the ?bugs section of the user manual?" Is it something that I, who has almost zero knowledge of the workings of the compiler, can do? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 1 19:15:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Aug 2015 19:15:30 -0000 Subject: [GHC] #10134: Pattern Matching Causes Infinite Type Error In-Reply-To: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> References: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> Message-ID: <060.de89c5ec4fba27df9860c2ef9fb1beb7@haskell.org> #10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * Attachment "T10134.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 1 19:15:59 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Aug 2015 19:15:59 -0000 Subject: [GHC] #10134: Pattern Matching Causes Infinite Type Error In-Reply-To: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> References: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> Message-ID: <060.47cb64d39b25dfd94de612fea2c63cfa@haskell.org> #10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * Attachment "ClashPrelude.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 1 19:35:52 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Aug 2015 19:35:52 -0000 Subject: [GHC] #10724: ghci crashing when using copy/paste in Gnome Terminal on Debian Jessie Message-ID: <048.3d43e86871e2f47f3491fb5fe466e924@haskell.org> #10724: ghci crashing when using copy/paste in Gnome Terminal on Debian Jessie -------------------------------------+------------------------------------- Reporter: martinvlk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When I copy/paste text from a ghci instance running in the terminal, quite often it stops responding with the following message: : hGetChar: hardware fault (Input/output error) I then have to kill it (Ctrl-C) and restart. It's GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help but I remember the same was happening in 7.10.1 too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 1 19:37:28 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Aug 2015 19:37:28 -0000 Subject: [GHC] #10724: ghci crashing when using copy/paste in Gnome Terminal on Debian Jessie In-Reply-To: <048.3d43e86871e2f47f3491fb5fe466e924@haskell.org> References: <048.3d43e86871e2f47f3491fb5fe466e924@haskell.org> Message-ID: <063.dccedcab92f37954be8d45672693a43c@haskell.org> #10724: ghci crashing when using copy/paste in Gnome Terminal on Debian Jessie -------------------------------+----------------------------------------- Reporter: martinvlk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Changes (by martinvlk): * failure: None/Unknown => GHCi crash * os: Unknown/Multiple => Linux -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 1 19:43:04 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Aug 2015 19:43:04 -0000 Subject: [GHC] #10134: Pattern Matching Causes Infinite Type Error In-Reply-To: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> References: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> Message-ID: <060.4df6f59d9b389c052372cbbfae224869@haskell.org> #10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): To reproduce this problem: * Download `T10134.hs` and `ClashPrelude.hs`, which is a further reduced version of `Dummy.lhs` above, without any dependencies. * Run `ghc-7.8.4 T10134.hs -fforce-recomp -XDataKinds -XTypeOperators -XConstraintKinds -XTypeFamilies -XNoMonomorphismRestriction -XNoMonoLocalBinds`. (I didn't add these as language pragmas to the file, to show that clash- ghc sets them) * This is the error: {{{ Occurs check: cannot construct the infinite type: t0 ~ (t0 + 1) - 1 The type variable ?t0? is ambiguous When checking that ?dSnd? has the inferred type ?Bool? Probable cause: the inferred type is ambiguous In an equation for ?nextDummy?: nextDummy d = Dummy {vec = vec dFst} where (dFst, dSnd) = nextDummy' d }}} To reproduce with clash-ghc itself, I did something like this: {{{ $ cabal sandbox init $ cabal install --with-ghc=ghc-7.8.4 clash-ghc==0.4.1 --constraint=clash- lib==0.4.1 $ ./cabal-sandbox/bin/clash -package-db=.cabal-sandbox/x86_64-linux- ghc-7.8.4-packages.conf.d/ T10134.hs` ... same error ... }}} What's going on is this: * clash-ghc is basically a copy of ghc-bin, with some modifications. * One of the modifications is that by default it sets `TypeFamilies` and some other language extensions, and unsets `MonoMorphismRestriction`. * Normally, when you set `TypeFamilies` (or `GADTs`), you also get `MonoLocalBinds`. clash-ghc doesn't call the code that does that however, and instead manipulates DynFlags directly. * So to reproduce the problem with just ghc, we have to set `TypeFamilies`, but unset `MonoLocalBinds`. `T10134.hs` compiles fine with ghc-7.10.2 and HEAD. It does show the following warning: {{{ Redundant constraint: Positive (2 * (n + d)) In the type signature for: nextDummy' :: Positive (2 * (n + d)) => Dummy n d -> (Dummy n d, Bool) }}} After removing that constraint, the example compiles with ghc-7.8.4 also. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 1 19:44:48 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Aug 2015 19:44:48 -0000 Subject: [GHC] #10134: Pattern Matching Causes Infinite Type Error In-Reply-To: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> References: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> Message-ID: <060.9d771da59703fee8fcc19ab4869b92fc@haskell.org> #10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => new Comment: That's all I know. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 1 19:47:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Aug 2015 19:47:40 -0000 Subject: [GHC] #10724: ghci crashing when using copy/paste in Gnome Terminal on Debian Jessie In-Reply-To: <048.3d43e86871e2f47f3491fb5fe466e924@haskell.org> References: <048.3d43e86871e2f47f3491fb5fe466e924@haskell.org> Message-ID: <063.161faeb50f53d101ae29653f26a01250@haskell.org> #10724: ghci crashing when using copy/paste in Gnome Terminal on Debian Jessie -------------------------------+----------------------------------------- Reporter: martinvlk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #3656 | Differential Revisions: -------------------------------+----------------------------------------- Changes (by thomie): * cc: nomeata (added) * related: => #3656 Comment: cc nomeata, since the title mentions Debian. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 1 22:55:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Aug 2015 22:55:00 -0000 Subject: [GHC] #9228: Internal compiler error with -O1 and -O2 In-Reply-To: <047.85eabab762dce9ba63253004f8d47fe4@haskell.org> References: <047.85eabab762dce9ba63253004f8d47fe4@haskell.org> Message-ID: <062.902dcbd218e2160426ede7e7f2301fa9@haskell.org> #9228: Internal compiler error with -O1 and -O2 -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8892 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => duplicate Comment: This should be fixed. Please reopen if it isn't. You can download 7.8.4 here: https://www.haskell.org/ghc/download_ghc_7_8_4#windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 1 23:09:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Aug 2015 23:09:37 -0000 Subject: [GHC] #8842: Make sure msys2 builds non emulating binaries In-Reply-To: <046.86a6364bab91651953306fe81692398f@haskell.org> References: <046.86a6364bab91651953306fe81692398f@haskell.org> Message-ID: <061.1f4e0e76fc8958f924cb2cac6430036d@haskell.org> #8842: Make sure msys2 builds non emulating binaries -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.8.1-rc2 Resolution: fixed | Keywords: msys2 Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 1 23:48:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Aug 2015 23:48:34 -0000 Subject: [GHC] #9832: Get rid of PERL dependency of `ghc-split` In-Reply-To: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> References: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> Message-ID: <057.61823e8c1c0564103ff5c0c80c2b3d1d@haskell.org> #9832: Get rid of PERL dependency of `ghc-split` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Phyx- Type: task | Status: new Priority: high | Milestone: 7.12.1 Component: Driver | Version: Resolution: | Keywords: perl Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thoughtpolice): The goal wasn't to reduce binary size, it was to make it possible to not track `ghc-tarballs` as a git repository, because it's a useless git repository that we only need for MinGW during GHC's build, and updating it is painful and using it on Windows sucks. See here: https://phabricator.haskell.org/D339 - This patch actually completely removes the need for `ghc-tarballs` on Windows and instead lets Windows users download an appropriate binary package that is simply untarred into the root (IIRC). It also means it is far, far easier to test and update compilers that are required on Windows. The problem here is that it turns out we were relying on the MinGW tools to also have perl, so we could run `ghc-split` during the build process, because the libraries need it. Rewriting it in Haskell means we can drop `ghc-tarballs` which includes the whole of MinGW for just some builds of binutils, which is not only smaller, it's saner. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 01:10:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 01:10:37 -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.e452b1c1959666a4535c31055a2f2114@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 7.12.1 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by akio): Replying to [comment:43 nomeata]: > I think the conclusion was that Nested CPR was not worth it. The branch is still there if someone wants to pick it up. Unassigning. Why is it not worth it? If there is a chance that the branch can be improved to the point that it can be merged, I'm interested in trying. The lack of nested CPR has been the most frequent reason that I have to use unboxed types manually. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 01:11:13 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 01:11:13 -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.aa6e9b2f073a8e9f407e7b32588e1dc7@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 7.12.1 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by akio): * cc: akio (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 03:41:17 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 03:41:17 -0000 Subject: [GHC] #10723: Make declarations in signatures "weakly bound" until they are used In-Reply-To: <045.468e4f2d1d9f6be5dd513d2c8bb6c010@haskell.org> References: <045.468e4f2d1d9f6be5dd513d2c8bb6c010@haskell.org> Message-ID: <060.46818d98d3673cc92a65990299893038@haskell.org> #10723: Make declarations in signatures "weakly bound" until they are used -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.11 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by ezyang: Old description: > Suppose you are the author of a library in a Backpack world, and you > publish a signature package which defines the entire public facing > interface of your library. The library `foo` which uses of your library > decides to `include` the signature package for convenience, but actually > only uses a small portion of the API. > > Later, you make a BC-breaking change in one part of the library and > release a new signature package. The library `bar` which uses your > library includes this NEW signature package, using a different portion of > the API which was unaffected by the by the BC change. > > Now, a hapless user tries to use `foo` and `bar`, but Backpack complains > that the requirements are not compatible. > > What's the problem here? The practice of writing reusable signature > packages for people to use caused the requirements of `foo` and `bar` to > become too large, since they included a lot of junk that these libraries > didn't actually use. It would be far better if you could `include` a > signature package, but only "require" the bits of it that you actually > used! > > How can we achieve this? > > 1. We augment the `ModIface` of signature merges (#10690) to record > whether or not a declaration was (transitively) used or not by some > module. Used declarations must be filled, but unused ones are treated > more flexibly: if they are merged with a different, incompatible but used > requirement, they disappear, and we don't check if an implementing module > actually implemented the declaration. (If two unused incompatible > requirements are merged, we just erase the name.) > > 2. How do we compute the usage info? I think it will have to be done > during shaping (which runs the renamer). We only need to annotate each > declaration a signature with the transitive set of names from other > signatures that it has used--this can be incrementally computed. (It's > not necessary to annotate declarations in modules, since they are always > assumed to use holes). Then whenever a declaration from a signature is > used in a module, we mark its transitive set as used. This information > can then be used later when constructing the merged `ModIface` which > represents the "public requirement" of the package. > > So, for example, a package containing only signatures would contain all > unused declarations (however, they may start being used by a package > which includes them). Any unused declaration which isn't mixed with > another incompatible declaration can be imported (causing it to be used), > but we will complain if you try to use a name and we can't tell which > declaration to use. New description: Suppose you are the author of a library in a Backpack world, and you publish a signature package which defines the entire public facing interface of your library. The library `foo` which uses of your library decides to `include` the signature package for convenience, but actually only uses a small portion of the API. Later, you make a BC-breaking change in one part of the library and release a new signature package. The library `bar` which uses your library includes this NEW signature package, using a different portion of the API which was unaffected by the by the BC change. Now, a hapless user tries to use `foo` and `bar`, but Backpack complains that the requirements are not compatible. What's the problem here? The practice of writing reusable signature packages for people to use caused the requirements of `foo` and `bar` to become too large, since they included a lot of junk that these libraries didn't actually use. It would be far better if you could `include` a signature package, but only "require" the bits of it that you actually used! How can we achieve this? 1. We augment the `ModIface` of signature merges (#10690) to record whether or not a declaration was (transitively) used or not by some module. Used declarations must be filled, but unused ones are treated more flexibly: if they are merged with a different, incompatible but used requirement, they disappear, and we don't check if an implementing module actually implemented the declaration. (If two unused incompatible requirements are merged, we just erase the name.) 2. How do we compute the usage info? I think it will have to be done during shaping (which runs the renamer). We only need to annotate each declaration a signature with the transitive set of names from other signatures that it has used--this can be incrementally computed. (It's not necessary to annotate declarations in modules, since they are always assumed to use holes). Then whenever a declaration from a signature is used in a module, we mark its transitive set as used. This information can then be used later when constructing the merged `ModIface` which represents the "public requirement" of the package. So, for example, a package containing only signatures would contain all unused declarations (however, they may start being used by a package which includes them). Any unused declaration which isn't mixed with another incompatible declaration can be imported (causing it to be used), but we will complain if you try to use a name and we can't tell which declaration to use. (PS: another moral here, is that `include`s are bad UNLESS you are including a signature package! Because an include for a concrete module is a dependency you can't override...) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 03:41:54 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 03:41:54 -0000 Subject: [GHC] #9848: List.all does not fuse In-Reply-To: <049.2f5a48f3cdf200c755c1a1e10fe7787f@haskell.org> References: <049.2f5a48f3cdf200c755c1a1e10fe7787f@haskell.org> Message-ID: <064.7edcd6a3a9ded1f5488423e65a6690cd@haskell.org> #9848: List.all does not fuse -------------------------------------+------------------------------------- Reporter: klapaucius | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by akio): It looks like the problem is in how `foldMap` for lists is defined. Now `all` is defined in terms of `foldMap`, and `foldMap` is defined in terms of `foldr`. However, the unfolding for `foldMap` for lists contains a recursive function, rather than a reference to `foldr`. This means any list function defined in terms of `foldMap` has no chance of fusion. Adding an INLINE pragma to the default definition for `foldMap` seems to fix the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 03:42:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 03:42:37 -0000 Subject: [GHC] #9848: List.all does not fuse In-Reply-To: <049.2f5a48f3cdf200c755c1a1e10fe7787f@haskell.org> References: <049.2f5a48f3cdf200c755c1a1e10fe7787f@haskell.org> Message-ID: <064.5e9e7113c5de6b8b5c9a982c79a84afc@haskell.org> #9848: List.all does not fuse -------------------------------------+------------------------------------- Reporter: klapaucius | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by akio): I'm preparing a patch, but what is a good way for testing this? Should I add a performance test? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 05:30:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 05:30:10 -0000 Subject: [GHC] #10725: Figure out how to support type synonym implementions of abstract data Message-ID: <045.980e660de8478100fba0b108c0422308@haskell.org> #10725: Figure out how to support type synonym implementions of abstract data -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- A classic example we have used when describing Backpack is that you might want to abstract over is different types of strings: String, ByteString, Text, etc. Unfortunately, with every implementation of Backpack we have had so far, you can't actually do this! For example, say you use a type synonym to get an existing data type to the "right name"; you get this error: {{{ A.hs-boot:2:6: Type constructor `T' has conflicting definitions in the module and its hs-boot file Main module: type T = String Boot file: abstract(False) T No C type associated RecFlag NonRecursive FamilyInstance: none }}} How can we make this work? Could it be as simple as just relaxing the restriction here? This seems to work OK with shaping, so long as we refer to the type synonym (and not the original type in question!) If some type checker experts could weight in that would be quite useful. ---- Probably the biggest danger is interaction with machinery that works with type families. For example, this is accepted: {{{ -- A.hs-boot module A where data T -- B.hs {-# LANGUAGE TypeFamilies #-} module B where import {-# SOURCE #-} qualified A data T = T type family F a :: * type instance F A.T = Bool type instance F T = Int }}} This doesn't lead to unsoundness today, because A.T must always be defined in A.hs (and thus have a unique nominal identity). But it's dangerous for this to be accepted today with signatures, since T could refer to B.T. (The moral of the story is that after shaping, you have to recheck all pairs of families; you can't assume that because they were typechecked earlier that they're OK.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 05:32:04 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 05:32:04 -0000 Subject: [GHC] #10725: Figure out how to support type synonym implementions of abstract data In-Reply-To: <045.980e660de8478100fba0b108c0422308@haskell.org> References: <045.980e660de8478100fba0b108c0422308@haskell.org> Message-ID: <060.90549ba311f1fe90111a4b5dd7634fd2@haskell.org> #10725: Figure out how to support type synonym implementions of abstract data -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by ezyang: Old description: > A classic example we have used when describing Backpack is that you might > want to abstract over is different types of strings: String, ByteString, > Text, etc. > > Unfortunately, with every implementation of Backpack we have had so far, > you can't actually do this! For example, say you use a type synonym to > get an existing data type to the "right name"; you get this error: > > {{{ > A.hs-boot:2:6: > Type constructor `T' has conflicting definitions in the module and > its hs-boot file > Main module: type T = String > Boot file: abstract(False) T > No C type associated > RecFlag NonRecursive > FamilyInstance: none > }}} > > How can we make this work? Could it be as simple as just relaxing the > restriction here? This seems to work OK with shaping, so long as we refer > to the type synonym (and not the original type in question!) If some type > checker experts could weight in that would be quite useful. > > ---- > > Probably the biggest danger is interaction with machinery that works with > type families. For example, this is accepted: > > {{{ > -- A.hs-boot > module A where > data T > > -- B.hs > {-# LANGUAGE TypeFamilies #-} > module B where > import {-# SOURCE #-} qualified A > > data T = T > > type family F a :: * > type instance F A.T = Bool > type instance F T = Int > }}} > > This doesn't lead to unsoundness today, because A.T must always be > defined in A.hs (and thus have a unique nominal identity). But it's > dangerous for this to be accepted today with signatures, since T could > refer to B.T. (The moral of the story is that after shaping, you have to > recheck all pairs of families; you can't assume that because they were > typechecked earlier that they're OK.) New description: A classic example we have used when describing Backpack is that you might want to abstract over is different types of strings: String, ByteString, Text, etc. Unfortunately, with every implementation of Backpack we have had so far, you can't actually do this! For example, say you use a type synonym to get an existing data type to the "right name"; you get this error: {{{ A.hs-boot:2:6: Type constructor `T' has conflicting definitions in the module and its hs-boot file Main module: type T = String Boot file: abstract(False) T No C type associated RecFlag NonRecursive FamilyInstance: none }}} How can we make this work? Could it be as simple as just relaxing the restriction here? This seems to work OK with shaping, so long as we refer to the type synonym (and not the original type in question!) If some type checker experts could weight in that would be quite useful. ---- Probably the biggest danger is interaction with machinery that works with type families. For example, this is accepted: {{{ -- A.hs-boot module A where data T -- B.hs {-# LANGUAGE TypeFamilies #-} module B where import {-# SOURCE #-} qualified A data T = T type family F a :: * type instance F A.T = Bool type instance F T = Int }}} This doesn't lead to unsoundness today, because A.T must always be defined in A.hs (and thus have a unique nominal identity). But with synonyms (or even hs-boot files that don't have the "defined in the implementing module" requirement) it's dangerous; we need to notice that the type instance is inconsistent when we finally see the implementation. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 07:21:26 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 07:21:26 -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.fa95514a9477d59544b197b68ce628e6@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 7.12.1 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): I do not know how much the code changed in master... just give it a try! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 07:30:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 07:30:45 -0000 Subject: [GHC] #10159: cabal build/ghc compiler causes sudden hard reboot of my computer! In-Reply-To: <046.f6a8819131c1ac525f6581f5be865c05@haskell.org> References: <046.f6a8819131c1ac525f6581f5be865c05@haskell.org> Message-ID: <061.d6508d726c109118eb329c4fbd7c25d7@haskell.org> #10159: cabal build/ghc compiler causes sudden hard reboot of my computer! ---------------------------------+----------------------------------------- Reporter: jamshid | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: worksforme | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by gidyn): Replying to [comment:5 jamshid]: > First, why doesn't anything else trigger this, even when I rev up all my cores with processes running an empty loop.... You need a proper CPU stress test. ''What'' the CPU is doing at 100% makes a big difference. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 08:25:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 08:25:45 -0000 Subject: [GHC] #10692: Replace (SourceText, FastString) with WithSourceText data type In-Reply-To: <044.c56d65db37c6df403dcc678377793b55@haskell.org> References: <044.c56d65db37c6df403dcc678377793b55@haskell.org> Message-ID: <059.d256903d6b17c9fad81573ae1312e7e6@haskell.org> #10692: Replace (SourceText,FastString) with WithSourceText data type -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"15dd7007275a5dcdae2c9f104773eceaa56590dc/ghc" 15dd7007/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="15dd7007275a5dcdae2c9f104773eceaa56590dc" Replace (SourceText,FastString) with StringLiteral data type Summary: Phab:D907 introduced SourceText for a number of data types, by replacing FastString with (SourceText,FastString). Since this has an Outputable instance, no warnings are generated when ppr is called on it, but unexpected output is generated. See Phab:D1096 for an example of this. Replace the (SourceText,FastString) tuples with a new data type, ```lang=hs data StringLiteral = StringLiteral SourceText FastString ``` Update haddock submodule accordingly Test Plan: ./validate Reviewers: hvr, austin, rwbarton, trofi, bgamari Reviewed By: trofi, bgamari Subscribers: thomie, trofi, rwbarton, mpickering Differential Revision: https://phabricator.haskell.org/D1101 GHC Trac Issues: #10692 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 09:32:26 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 09:32:26 -0000 Subject: [GHC] #9848: List.all does not fuse In-Reply-To: <049.2f5a48f3cdf200c755c1a1e10fe7787f@haskell.org> References: <049.2f5a48f3cdf200c755c1a1e10fe7787f@haskell.org> Message-ID: <064.f58a0948de38acd3156ec980c2335425@haskell.org> #9848: List.all does not fuse -------------------------------------+------------------------------------- Reporter: klapaucius | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): > Should I add a performance test? Yes. Usually with list fusion you can create a test that allocates almost nothing if fusion kicks in, but allocates a lot of it does not. Alternatively, you can copy the code from http://hackage.haskell.org/package/list-fusion-probe-0.1.0.3/docs/src /Data-List-Fusion-Probe.html into the test case and wrap the argument to `all` with `fuseThis`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 09:42:12 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 09:42:12 -0000 Subject: [GHC] #9233: Compiler performance regression In-Reply-To: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> References: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> Message-ID: <062.e5a0cc546a8660459dd9c70e829d8d3b@haskell.org> #9233: Compiler performance regression -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D73 -------------------------------------+------------------------------------- Changes (by thomie): * priority: low => normal * failure: None/Unknown => Compile-time performance bug * os: Windows => Unknown/Multiple Comment: Still needs a test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 09:51:03 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 09:51:03 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMDIxNjogQWxsb3cgYXJyIOKIpyAoZmlyc3Qg?= =?utf-8?q?=E2=88=A8_=28***=29=29_as_minimal_definition_of_Arrow_?= =?utf-8?q?instance?= In-Reply-To: <048.64b271a00a46843da0df000240882f80@haskell.org> References: <048.64b271a00a46843da0df000240882f80@haskell.org> Message-ID: <063.5793b284be89de2f58ee29d8969c4d68@haskell.org> #10216: Allow arr ? (first ? (***)) as minimal definition of Arrow instance -------------------------------------+------------------------------------- Reporter: strake888 | Owner: ekmett Type: bug | Status: infoneeded Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => infoneeded Comment: Yes, I think it would be best to put together a formal proposal and send it through the core libraries committee. It needn't be much effort and it sounds like it shouldn't be terribly controversial but I would like to make sure that this goes through the correct channels. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 09:57:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 09:57:33 -0000 Subject: [GHC] #10134: Pattern Matching Causes Infinite Type Error In-Reply-To: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> References: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> Message-ID: <060.8a7e3c67b3650fce0672aa067ab816b0@haskell.org> #10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by darchon): * cc: darchon (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 09:59:48 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 09:59:48 -0000 Subject: [GHC] #9234: Compiled code performance regression In-Reply-To: <047.2cda529fb09879fe11b16d1bba281c0e@haskell.org> References: <047.2cda529fb09879fe11b16d1bba281c0e@haskell.org> Message-ID: <062.869411aa6ec415617442ed2006e4818b@haskell.org> #9234: Compiled code performance regression -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * failure: None/Unknown => Runtime performance bug * resolution: => duplicate Comment: There are currently 184 [https://ghc.haskell.org/trac/ghc/query?status=!closed&failure=Runtime+performance+bug open tickets] concerning runtime performance. Since this one is the least actionable (doesn't have any code attached), I'm going to go ahead and close it. nofib benchmark results are posted on https://perf.haskell.org/ghc/ nowadays, and the issue tracker is at https://github.com/nomeata/gipeda/issues. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 11:56:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 11:56:33 -0000 Subject: [GHC] #10705: make configure warn when ghc-tarballs is missing on windows and provide guidance to download it. In-Reply-To: <044.6a0cbb38e795506560cf63dc7c2184b5@haskell.org> References: <044.6a0cbb38e795506560cf63dc7c2184b5@haskell.org> Message-ID: <059.3152b8ca8b9fafa33c4cc1ddc7224dcc@haskell.org> #10705: make configure warn when ghc-tarballs is missing on windows and provide guidance to download it. -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9218 | Differential Revisions: Phab:D1108 -------------------------------------+------------------------------------- Comment (by Phyx-): I was wondering if the default flag for ./validate should be changed as well. Currently you can't do: {{{ git clone --recursive git://git.haskell.org/ghc.git && cd ghc ./validate }}} The workflow is a bit weird in which you need: {{{ git clone --recursive git://git.haskell.org/ghc.git && cd ghc ./boot ./configure --enable-tarballs-autodownload ./validate }}} Since `--enable-tarballs-autodownload` is ignored on anything not Windows and on Windows would only download the tarballs if missing, maybe it should be the default in `validate` ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 12:01:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 12:01:57 -0000 Subject: [GHC] #10726: Upgrade MingW-w64 distributions for windows Message-ID: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Build | Version: 7.11 System | Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #9218 #9014 Differential Revisions: | #10435 -------------------------------------+------------------------------------- This is the second part of splitting up #9218. The goal is to move `GHC x86` from `MingW` to `MingW-w64` and to upgrade both the `x86` and the `x86_64` toolchains shipped with `GHC` to newer versions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 12:02:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 12:02:29 -0000 Subject: [GHC] #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 In-Reply-To: <047.bc42599240078110c16528fec3996433@haskell.org> References: <047.bc42599240078110c16528fec3996433@haskell.org> Message-ID: <062.79b255ff338f5837f151410d76b34b6e@haskell.org> #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 -------------------------------------+------------------------------------- Reporter: malcolmw | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: windows, | exceptions Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #10726 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by Phyx-): * related: #9218 => #9218 #10726 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 12:03:02 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 12:03:02 -0000 Subject: [GHC] #9218: Upgrade the version of MinGW shipped with GHC In-Reply-To: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> References: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> Message-ID: <062.a31de88b0d467751304f939dabf6b847@haskell.org> #9218: Upgrade the version of MinGW shipped with GHC -------------------------------------+------------------------------------- Reporter: komadori | Owner: gintas Type: task | Status: patch Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9014 | Blocking: 9215 Related Tickets: #3390 #10705 | Differential Revisions: Phab:D339 #10726 | -------------------------------------+------------------------------------- Changes (by Phyx-): * related: #3390 #10705 => #3390 #10705 #10726 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 12:05:27 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 12:05:27 -0000 Subject: [GHC] #9014: GHC 7.8.2 Win64 tarball includes gfortran/gcj/python In-Reply-To: <045.6b2d2b3d1bd35df290e16aad746006bd@haskell.org> References: <045.6b2d2b3d1bd35df290e16aad746006bd@haskell.org> Message-ID: <060.f0c008fd8e704a2328660b75b50007cd@haskell.org> #9014: GHC 7.8.2 Win64 tarball includes gfortran/gcj/python ---------------------------------+----------------------------------------- Reporter: refold | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: 9218 Related Tickets: #10726 #9218 | Differential Revisions: ---------------------------------+----------------------------------------- Changes (by Phyx-): * owner: => Phyx- * related: => #10726 #9218 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 12:09:04 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 12:09:04 -0000 Subject: [GHC] #9014: GHC 7.8.2 Win64 tarball includes gfortran/gcj/python In-Reply-To: <045.6b2d2b3d1bd35df290e16aad746006bd@haskell.org> References: <045.6b2d2b3d1bd35df290e16aad746006bd@haskell.org> Message-ID: <060.36d51554345d2ee637c72ca7f2900616@haskell.org> #9014: GHC 7.8.2 Win64 tarball includes gfortran/gcj/python ---------------------------------+----------------------------------------- Reporter: refold | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: 9218 Related Tickets: #10726 #9218 | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by Phyx-): I am currently testing an upgrade to `GCC 5.1.1` for both `x86` and `x86_64` builds. It will be using the `dongsheng` daily builds from the `MinGW-w64` repository which has no `python` or `fortran` dependencies and so is significantly smaller. It however does seem to contain everything we need. This is done in #10726 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 12:13:07 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 12:13:07 -0000 Subject: [GHC] #10726: Upgrade MingW-w64 distributions for windows In-Reply-To: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> References: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> Message-ID: <059.cbda38ea3eebd89b512db076388e3a26@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #9014 | Differential Revisions: #10435 | -------------------------------------+------------------------------------- Comment (by Phyx-): Chosen `MinGW-w64` build for this are the `dongsheng` daily builds from the `MinGW-w64` repository. Which avoids the issues mentioned in #9014 . The `GCC` versions will be upgraded to `5.1.1`. To be complete the `dongsheng` builds contain: {{{ binutils 2.25 gdb 7.9.1 make 4.1 gmp 6.0.0 mpfr 3.1.3 mpc 1.0.3 isl 0.14.1 mingw-w64 master gcc 5.1.1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 12:28:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 12:28:32 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.22f823038a251644cfc42715c8c49663@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.12.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Fanael, could you test this with `ld.gold`? We already advise users to use gold on ARM; perhaps we should just do the same here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 12:36:59 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 12:36:59 -0000 Subject: [GHC] #7521: Accelerate examples does not compile with default value of -fsimpl-tick-factor In-Reply-To: <046.a165b81ceec1b63f8c0bcb4e673ec08e@haskell.org> References: <046.a165b81ceec1b63f8c0bcb4e673ec08e@haskell.org> Message-ID: <061.022317467fbc11fc2ce3ba064f5d7d94@haskell.org> #7521: Accelerate examples does not compile with default value of -fsimpl-tick- factor -------------------------------------+------------------------------------- Reporter: eamsden | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * priority: high => normal Comment: I'm not even convinced this should be considered to be a bug. Various programs require varying amounts of effort from the simplifier; it is fair to say that `accelerate` sits on the high end of this spectrum. Do we really want to set the default simplifier tick factor to accommodate this extreme case? For the moment I'm going to lower the priority of this ticket, although arguably we could just close it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 14:16:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 14:16:30 -0000 Subject: [GHC] #10459: -fsimple-tick-factor required In-Reply-To: <046.318589501785c7d424a25275b1b3f56a@haskell.org> References: <046.318589501785c7d424a25275b1b3f56a@haskell.org> Message-ID: <061.2b1638d70b0f234a1d9ba43a88146c0e@haskell.org> #10459: -fsimple-tick-factor required -------------------------------------+------------------------------------- Reporter: mikehat | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: fsimple- | tick-factor Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Here is the offending code from the SFML package, comment:1: {{{#!haskell module T10459 where data Transform = Transform { m00 :: !Float, m10 :: !Float, m20 :: !Float , m01 :: !Float, m11 :: !Float, m21 :: !Float , m02 :: !Float, m12 :: !Float, m22 :: !Float } abs_ (Transform a00 a01 a02 a03 a04 a05 a06 a07 a08) = (Transform (abs a00) (abs a01) (abs a02) (abs a03) (abs a04) (abs a05) (abs a06) (abs a07) (abs a08)) }}} Fails with 7.8.4 and higher, but not with 7.6.3. {{{ $ ghc-7.8.4 T10459.hs -fsimpl-tick-factor=200 -O -fforce-recomp [1 of 1] Compiling T10459 ( T10459.hs, T10459.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.4 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone $j_s1vT{v} [lid] 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: 73282 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 15:13:21 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 15:13:21 -0000 Subject: [GHC] #10584: Installation of SFML failed In-Reply-To: <047.3f075afc9f4ab001107536fb1c61104e@haskell.org> References: <047.3f075afc9f4ab001107536fb1c61104e@haskell.org> Message-ID: <062.cff907aaddb68099e7a4d4a76971ebdb@haskell.org> #10584: Installation of SFML failed -------------------------------------+------------------------------------- Reporter: SoleSoul | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * version: 7.10.1 => 7.8.4 Comment: Here is a test to reproduce the problem: {{{#!haskell module T10584 where data Transform = Transform { m00 :: !Float, m10 :: !Float, m20 :: !Float , m01 :: !Float, m11 :: !Float, m21 :: !Float , m02 :: !Float, m12 :: !Float, m22 :: !Float } abs_ (Transform a00 a01 a02 a03 a04 a05 a06 a07 a08) = (Transform (abs a00) (abs a01) (abs a02) (abs a03) (abs a04) (abs a05) (abs a06) (abs a07) (abs a08)) }}} Fails with 7.8.4 and higher, but not with 7.6.3. {{{ $ ghc-7.8.4 T10584.hs -fsimpl-tick-factor=200 -O -fforce-recomp [1 of 1] Compiling T10584 ( T10584.hs, T10584.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.4 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone $j_s1vT{v} [lid] 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: 73282 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 15:23:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 15:23:34 -0000 Subject: [GHC] #10459: -fsimple-tick-factor required In-Reply-To: <046.318589501785c7d424a25275b1b3f56a@haskell.org> References: <046.318589501785c7d424a25275b1b3f56a@haskell.org> Message-ID: <061.22330f0a535c4ac65e9776b607a63c30@haskell.org> #10459: -fsimple-tick-factor required -------------------------------------+------------------------------------- Reporter: mikehat | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: fsimple- | tick-factor Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): mikehat: I tried for a while to reproduce your problem, but failed up to now. Can you please try again in a cabal sandbox, and provide the following information: * exact commands that result in failure (cabal build? cabal test?) * which commit * which versions of dependencies * cabal version With the following settings I didn't have any problems running `cabal build`: * ghc-7.6.3 * commit ea9ee861d77f4c65543de4e00a8188856ba4d994 without the `-fsimpl- tick-factor=175` in the cabal file * these libraries installed: text-1.2.0.4 blaze-builder-0.3.3.4 * cabal-install 1.22.2.0 Cabal-1.22.2.0 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 15:23:56 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 15:23:56 -0000 Subject: [GHC] #10459: -fsimple-tick-factor required In-Reply-To: <046.318589501785c7d424a25275b1b3f56a@haskell.org> References: <046.318589501785c7d424a25275b1b3f56a@haskell.org> Message-ID: <061.0a72204ae3d906d711438ca46e113043@haskell.org> #10459: -fsimple-tick-factor required -------------------------------------+------------------------------------- Reporter: mikehat | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: fsimple- | tick-factor Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 15:38:56 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 15:38:56 -0000 Subject: [GHC] #10727: compiler/rename/RnSource.lhs:429:14-81: Irrefutable pattern failed Message-ID: <045.6d72ea026d80af4da5c6596bf3e52215@haskell.org> #10727: compiler/rename/RnSource.lhs:429:14-81: Irrefutable pattern failed -------------------------------------+------------------------------------- Reporter: doelie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Keywords: | Operating System: Linux Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- see bug.sh in: http://zwizwa.be/stuff/ghc_bug.tgz make: Entering directory `/home/tom/pub/darcs/meta/siso' ghc Test.hs [ 9 of 10] Compiling Code ( Code.hs, Code.o ) ghc: panic! (the 'impossible' happened) (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, _) 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 Sun Aug 2 16:11:27 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 16:11:27 -0000 Subject: [GHC] #10727: compiler/rename/RnSource.lhs:429:14-81: Irrefutable pattern failed In-Reply-To: <045.6d72ea026d80af4da5c6596bf3e52215@haskell.org> References: <045.6d72ea026d80af4da5c6596bf3e52215@haskell.org> Message-ID: <060.ccc9d015c9d65dddfdac6a3baece0350@haskell.org> #10727: compiler/rename/RnSource.lhs:429:14-81: Irrefutable pattern failed -------------------------------------+------------------------------------- Reporter: doelie | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: invalid | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => invalid Comment: Thank you for the report. I can reproduce this with 7.4.2, after installing `mtl-1.1.1.1`. Other versions of GHC (7.6 and higher, but also 7.2 and 7.0) report: {{{ Code.hs:203:10: Malformed instance: (MakeVar i, Flatten i) => CompRed (i -> Comp o) -> o }}} The code indeed looks wrong, so I'm closing this. Note that we no longer support 7.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 16:56:11 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 16:56:11 -0000 Subject: [GHC] #10398: Support consecutive named Haddock comments In-Reply-To: <047.7740b80be062ec1bb48c700ce8a4b3f6@haskell.org> References: <047.7740b80be062ec1bb48c700ce8a4b3f6@haskell.org> Message-ID: <062.bd1a0d887ccb3dc7599ab12c1e6c8993@haskell.org> #10398: Support consecutive named Haddock comments -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: | haddock/should_compile_flag_haddock/T10398 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1025 -------------------------------------+------------------------------------- Comment (by dmcclean): Thanks everyone! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 17:56:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 17:56:42 -0000 Subject: [GHC] #10603: Output of -ddump-splices is parenthesized incorrectly In-Reply-To: <050.70ab9071ed50ac22038e86553f4b759c@haskell.org> References: <050.70ab9071ed50ac22038e86553f4b759c@haskell.org> Message-ID: <065.3b00a8f35f5f8757faee38a379bc3b15@haskell.org> #10603: Output of -ddump-splices is parenthesized incorrectly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: dnusbaum Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10703 | Differential Revisions: Phab:D1114 -------------------------------------+------------------------------------- Comment (by osa1): Just to keep this ticket updated: There are some other, related problems with GHC printing that made it to the testsuite. Example: https://github.com/ghc/ghc/blob/5ff4daddd9bc8f424d8f71fb01ebbbae9d608cdf/testsuite/tests/ghci/scripts/T10248.stderr#L8 this is not a valid syntax. (needs a paren around the function) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 17:58:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 17:58:20 -0000 Subject: [GHC] #7944: GHC goes into an apparently infinite loop at -O2 In-Reply-To: <042.860ea78ae85c4a928feb9d490c6ef1e4@haskell.org> References: <042.860ea78ae85c4a928feb9d490c6ef1e4@haskell.org> Message-ID: <057.9daa4530b4e0a06f4e423173e9fc2778@haskell.org> #7944: GHC goes into an apparently infinite loop at -O2 -------------------------------------+------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #5550 #8852 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): `-fno-spec-constr` indeed fixes the problem. I reduced the test code some more, but it still requires `vector`. {{{ $ cabal install vector # cabal gave me vector-0.10.12.3 $ ghc-7.10.2 -O2 --make Repro.hs # also fails with ghc-7.11.20150711 }}} {{{#!haskell module Repro where import qualified Data.Vector as V import qualified IntMap as I constructMap :: V.Vector (Int, [Int]) -> I.IntMap [Int] constructMap = V.foldl' go I.empty where go m (k,v) = snd $ I.insertWith (++) k v m }}} {{{#!haskell module IntMap where import Data.Bits ((.&.), complement, xor) import GHC.Num (Num(..)) import GHC.Real (fromIntegral) type Nat = Word natFromInt :: Key -> Nat natFromInt i = fromIntegral i intFromNat :: Nat -> Key intFromNat w = fromIntegral w data IntMap a = Nil | Tip Key a | Bin Prefix Mask (IntMap a) (IntMap a) type Prefix = Int type Mask = Int type Key = Int empty :: IntMap a empty = Nil insertWith :: (a -> a -> a) -> Key -> a -> IntMap a -> (Maybe a, IntMap a) insertWith f k x t = case t of Bin p m l r | nomatch k p m -> (Nothing, join k (Tip k x) p t) | zero k m -> let (found, l') = insertWith f k x l in (found, Bin p m l' r) | otherwise -> let (found, r') = insertWith f k x r in (found, Bin p m l r') Tip ky y | k == ky -> (Just y, Tip k (f x y)) | otherwise -> (Nothing, join k (Tip k x) ky t) Nil -> (Nothing, Tip k x) join :: Prefix -> IntMap a -> Prefix -> IntMap a -> IntMap a join p1 t1 p2 t2 | zero p1 m = Bin p m t1 t2 | otherwise = Bin p m t2 t1 where m = branchMask p1 p2 p = mask p1 m zero :: Key -> Mask -> Bool zero i m = (natFromInt i) .&. (natFromInt m) == 0 nomatch :: Key -> Prefix -> Mask -> Bool nomatch i p m = (mask i m) /= p mask :: Key -> Mask -> Prefix mask i m = maskW (natFromInt i) (natFromInt m) maskW :: Nat -> Nat -> Prefix maskW i m = intFromNat (i .&. (complement (m-1) `xor` m)) branchMask :: Prefix -> Prefix -> Mask branchMask p1 p2 = intFromNat (highestBitMask (natFromInt p1)) highestBitMask :: Nat -> Nat highestBitMask x1 = x1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 18:25:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 18:25:29 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMDIxNjogQWxsb3cgYXJyIOKIpyAoZmlyc3Qg?= =?utf-8?q?=E2=88=A8_=28***=29=29_as_minimal_definition_of_Arrow_?= =?utf-8?q?instance?= In-Reply-To: <048.64b271a00a46843da0df000240882f80@haskell.org> References: <048.64b271a00a46843da0df000240882f80@haskell.org> Message-ID: <063.1b5425b431c47971a794a11eb182a00d@haskell.org> #10216: Allow arr ? (first ? (***)) as minimal definition of Arrow instance -------------------------------------+------------------------------------- Reporter: strake888 | Owner: ekmett Type: bug | Status: infoneeded Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by strake888: Old description: > Add default definitions of `first`, `second` in terms of `(***)` to let > one define an `Arrow` instance in terms of `(***)` rather than `first`, > which is sometimes more elegant. New description: Add default definitions of `first`, `second` in terms of `(***)` to let one define an `Arrow` instance in terms of `(***)` rather than `first`, which is sometimes more elegant or convenient. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 18:31:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 18:31:34 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMDIxNjogQWxsb3cgYXJyIOKIpyAoZmlyc3Qg?= =?utf-8?q?=E2=88=A8_=28***=29=29_as_minimal_definition_of_Arrow_?= =?utf-8?q?instance?= In-Reply-To: <048.64b271a00a46843da0df000240882f80@haskell.org> References: <048.64b271a00a46843da0df000240882f80@haskell.org> Message-ID: <063.6eee6312e2e3f426d98b28b2479eb8c2@haskell.org> #10216: Allow arr ? (first ? (***)) as minimal definition of Arrow instance -------------------------------------+------------------------------------- Reporter: strake888 | Owner: ekmett Type: bug | Status: infoneeded Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by strake888): Replying to [comment:7 bgamari]: > Yes, I think it would be best to put together a formal proposal and send it through the core libraries committee. Done. (I wasn't sure earlier whether to do so as the core-libraries- committee chair had already seen this ticket.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 19:40:07 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 19:40:07 -0000 Subject: [GHC] #10726: Upgrade MingW-w64 distributions for windows In-Reply-To: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> References: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> Message-ID: <059.dbb974315664b299cd9c2c6efa03dd4f@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: patch Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #9014 | Differential Revisions: Phab:D1123 #10435 | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D1123 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 20:19:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 20:19:30 -0000 Subject: [GHC] #10726: Upgrade MingW-w64 distributions for windows In-Reply-To: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> References: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> Message-ID: <059.5e76e20a84d253f5601aee600b33bf47@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: patch Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #9014 | Differential Revisions: Phab:D1123 #10435 | -------------------------------------+------------------------------------- Comment (by awson): Could we, perhaps, use Msys2 builds for this? They are of a high quality and pretty well supported. Also they have gcc-5.2 and, most important, recently released binutils-2.25.1 which have a very important bug (wrong linking of 64-bit import libraries generated by MS linker) fixed. As of today the transitive closure of packages required is (I believe) this: {{{ mingw-w64-x86_64-crt-git-5.0.0.4531.49c7046-1 mingw-w64-x86_64-winpthreads-git-5.0.0.4538.78dca70-1 mingw-w64-x86_64-headers-git-5.0.0.4531.49c7046-1 mingw-w64-x86_64-libwinpthread-git-5.0.0.4538.78dca70-1 mingw-w64-x86_64-zlib-1.2.8-8 mingw-w64-x86_64-isl-0.14.1-2 mingw-w64-x86_64-mpc-1.0.3-2 mingw-w64-x86_64-mpfr-3.1.3.p0-2 mingw-w64-x86_64-gmp-6.0.0-3 mingw-w64-x86_64-gcc-libs-5.2.0-3 mingw-w64-x86_64-binutils-2.25.1-1 mingw-w64-x86_64-libiconv-1.14-5 mingw-w64-x86_64-gcc-5.2.0-3 }}} The new repo of Msys2 packages is http://repo.msys2.org/mingw. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 20:26:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 20:26:41 -0000 Subject: [GHC] #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options Message-ID: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: simonmar Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 7.10.2 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- As discussed in this issue: https://github.com/commercialhaskell/stack/issues/680 stack is one example of a program that optimistically turned on "-N". Indeed, it feels like a reasonable and even safe option for a multithreaded program. Unfortunately, -N currently guarantees bad performance on large machines and especially on large machines with hyperthreading. Pretty much one should ship an executable with -N by default as of GHC 7.8 and 7.10 IMHO. Unfortunately, even if stack did get a speedup at, say, 4 or 8 cores, it would not be good to ship it with "-N8" either. This would be an unreasonable choice on small, one or two core machines. What we need is a way to say that the program can productively use parallelism up to a certain upper bound, but that fewer threads should be used if there are not enough cores available. I propose "-N<=8" as a potential syntax. Currently, this behavior can be achieved with `setNumCapabilities`/`getNumProcessors`, but I think it's worth a command line RTS option. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 20:27:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 20:27:24 -0000 Subject: [GHC] #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options In-Reply-To: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> References: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> Message-ID: <062.ef59037d757eb464aa905e115ff88bf1@haskell.org> #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by rrnewton: Old description: > As discussed in this issue: > > https://github.com/commercialhaskell/stack/issues/680 > > stack is one example of a program that optimistically turned on "-N". > Indeed, it feels like a reasonable and even safe option for a > multithreaded program. Unfortunately, -N currently guarantees bad > performance on large machines and especially on large machines with > hyperthreading. Pretty much one should ship an executable with -N by > default as of GHC 7.8 and 7.10 IMHO. > > Unfortunately, even if stack did get a speedup at, say, 4 or 8 cores, it > would not be good to ship it with "-N8" either. This would be an > unreasonable choice on small, one or two core machines. > > What we need is a way to say that the program can productively use > parallelism up to a certain upper bound, but that fewer threads should be > used if there are not enough cores available. I propose "-N<=8" as a > potential syntax. > > Currently, this behavior can be achieved with > `setNumCapabilities`/`getNumProcessors`, but I think it's worth a command > line RTS option. New description: As discussed in this issue: https://github.com/commercialhaskell/stack/issues/680 stack is one example of a program that optimistically turned on "-N". Indeed, it feels like a reasonable and even safe option for a multithreaded program. Unfortunately, -N currently guarantees bad performance on large machines and especially on large machines with hyperthreading. No one should ship an executable with -N by default as of GHC 7.8 and 7.10 IMHO. Unfortunately, even if stack did get a speedup at, say, 4 or 8 cores, it would not be good to ship it with "-N8" either. This would be an unreasonable choice on small, one or two core machines. What we need is a way to say that the program can productively use parallelism up to a certain upper bound, but that fewer threads should be used if there are not enough cores available. I propose "-N<=8" as a potential syntax. Currently, this behavior can be achieved with `setNumCapabilities`/`getNumProcessors`, but I think it's worth a command line RTS option. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 20:46:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 20:46:41 -0000 Subject: [GHC] #10726: Upgrade MingW-w64 distributions for windows In-Reply-To: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> References: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> Message-ID: <059.3ca28009944c663f51f6f0468aade17c@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: patch Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #9014 | Differential Revisions: Phab:D1123 #10435 | -------------------------------------+------------------------------------- Comment (by Phyx-): I have no problems with that. I'll try to modify the script tomorrow and let validate run over night. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 22:56:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 22:56:44 -0000 Subject: [GHC] #8224: Excessive system time -- new IO manager problem? In-Reply-To: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> References: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> Message-ID: <062.d6874861685906bd051f852f3dd9e440@haskell.org> #8224: Excessive system time -- new IO manager problem? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: IO | Manager, System Time Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9221 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * related: => #9221 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 22:57:09 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 22:57:09 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.53e88b496c9c9c70b4aa1254f179acf8@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * related: #910 => #910, #8224 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 23:00:12 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 23:00:12 -0000 Subject: [GHC] #7944: GHC goes into an apparently infinite loop at -O2 In-Reply-To: <042.860ea78ae85c4a928feb9d490c6ef1e4@haskell.org> References: <042.860ea78ae85c4a928feb9d490c6ef1e4@haskell.org> Message-ID: <057.742612509fab4046224c6306a5b0e82a@haskell.org> #7944: GHC goes into an apparently infinite loop at -O2 -------------------------------------+------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #5550 #8852 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by amosrobinson): Hi, I had a go reducing this more. I only have ghc 7.8.3, so would someone be able to try this on head? {{{ #!haskell module T7944 where import GHC.Exts -- Force specialisation of "go" data SPEC = SPEC | SPEC2 {-# ANN type SPEC ForceSpecConstr #-} -- This is more or less just an ordinary fold go :: SPEC -> [a] -> IntMap a -> IntMap a go SPEC [] m = m go SPEC (_:xs) m = go SPEC xs -- This would be the "worker function" of the fold $ Unary m -- Both constructors are necessary, despite only one being used data IntMap a = Nil | Unary (IntMap a) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 23:11:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 23:11:19 -0000 Subject: [GHC] #7944: GHC goes into an apparently infinite loop at -O2 In-Reply-To: <042.860ea78ae85c4a928feb9d490c6ef1e4@haskell.org> References: <042.860ea78ae85c4a928feb9d490c6ef1e4@haskell.org> Message-ID: <057.016b189e8e56fc6656731a37c40070eb@haskell.org> #7944: GHC goes into an apparently infinite loop at -O2 -------------------------------------+------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #5550 #8852 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Yes, infinite loop with ghc-7.10.2 as well as ghc-7.11.20150711 (HEAD). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 23:27:16 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 23:27:16 -0000 Subject: [GHC] #7944: GHC goes into an apparently infinite loop at -O2 In-Reply-To: <042.860ea78ae85c4a928feb9d490c6ef1e4@haskell.org> References: <042.860ea78ae85c4a928feb9d490c6ef1e4@haskell.org> Message-ID: <057.459e624c6baba56472b133e2519a7df5@haskell.org> #7944: GHC goes into an apparently infinite loop at -O2 -------------------------------------+------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #5550 #8852 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by amosrobinson): Hmm. So I thought in this case, the is_too_recursive check should stop specialisation after a few runs. The counting of recursive constructors is only going down through applications though: I wonder whether it needs to handle lets, cases, etc? https://github.com/ghc/ghc/blob/master/compiler/specialise/SpecConstr.hs#L1807 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 23:46:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 23:46:33 -0000 Subject: [GHC] #10729: Type inference in GADT pattern matches Message-ID: <044.8d4c7c9c327df900f81fed1b4dd108c0@haskell.org> #10729: Type inference in GADT pattern matches -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When pattern matching against GADT constructors, GHC seems to have issues with inferring the type of the resulting expression. Minimal example: Assume the datatype: {{{ data D a where D :: D () }}} A simple function that pattern matches on it: {{{ a D = () }}} It is expected to have type `D a -> ()` (Note: not `D () -> ()`, existence of a `D` should ensure `()`, not the type signature), but instead it errors: {{{ error: Couldn't match expected type ?t? with actual type ?()? ?t? is untouchable inside the constraints: t1 ~ () bound by a pattern with constructor: D :: D (), in an equation for ?a? ?t? is a rigid type variable bound by the inferred type of a :: D t1 -> t }}} Note that the error goes away when we annotate the type of the function: {{{ b :: D a -> () -- no error b D = () }}} Or if we supply another branch that clarifies the type: {{{ c D = () -- no error c _ = () }}} But it reappears if the other branch doesn't provide anything to infer from: {{{ d D = () -- error d _ = undefined }}} The same issue happens in `case`: {{{ e x = case x of D -> () -- error }}} But only when the value being matched comes from outside: {{{ f = case D of D -> () -- no error }}} This behavior is reprooducible and identical in 7.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 23:51:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 23:51:41 -0000 Subject: [GHC] #10584: Installation of SFML failed In-Reply-To: <047.3f075afc9f4ab001107536fb1c61104e@haskell.org> References: <047.3f075afc9f4ab001107536fb1c61104e@haskell.org> Message-ID: <062.940af890a1481ca940304863d9b3f38e@haskell.org> #10584: Installation of SFML failed -------------------------------------+------------------------------------- Reporter: SoleSoul | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Reminiscent of #10421. With GHC 7.8.4, `-fsimpl-tick-factor=800` was enough and then GHC expanded out all the possible cases of positive and negative `a0i`. In GHC 7.10.1 `abs` has three cases (to handle negative zero correctly) so you really have to crank up the `-fsimpl-tick- factor`... Note that `abs` does not have any sort of `INLINE` pragma. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 00:04:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 00:04:49 -0000 Subject: [GHC] #10729: Type inference in GADT pattern matches In-Reply-To: <044.8d4c7c9c327df900f81fed1b4dd108c0@haskell.org> References: <044.8d4c7c9c327df900f81fed1b4dd108c0@haskell.org> Message-ID: <059.8de0bfb9ff18f9f2a4c4b4d8a4a674a0@haskell.org> #10729: Type inference in GADT pattern matches -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => invalid Comment: Replying to [ticket:10729 mniip]: > When pattern matching against GADT constructors, GHC seems to have issues with inferring the type of the resulting expression. > > Minimal example: Assume the datatype: > > {{{ > data D a where D :: D () > }}} > A simple function that pattern matches on it: > {{{ > a D = () > }}} > It is expected to have type `D a -> ()` Why not `a :: D a -> a`? This function definition has no principal type. See the very end of the user's guide section https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/data-type- extensions.html#gadt. The type of the function body is not rigid in your example, because you did not specify it with a type annotation, and the only information about the type comes from inside a pattern match on a refining constructor. It is one of the examples in the linked paper, in appendix A. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 03:23:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 03:23:45 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.9e5eccd4364339471714409a0d84e9ba@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by kazu-yamamoto): * cc: kazu-yamamoto (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 06:39:52 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 06:39:52 -0000 Subject: [GHC] #10543: MacOS: validate fails on \u In-Reply-To: <047.a887440a0df817cb06caf9fc53c8c2c9@haskell.org> References: <047.a887440a0df817cb06caf9fc53c8c2c9@haskell.org> Message-ID: <062.080c58166410f3fa579bfed14b3c4bf7@haskell.org> #10543: MacOS: validate fails on \u -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 7.10.1 Resolution: invalid | Keywords: cpp Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1004 -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:5 geoff]: > So, I was the one to add this line ? overriding `-Wno-invalid-pp-token -Wno-unicode -Wno-trigraphs` ? because these flags are not universally supported by clang. If anyone could help me understand this better, it would be appreciated. https://github.com/Homebrew/homebrew/issues/41777#issuecomment-122826887 I added a comment to the homebrew ticket explaining that GHC uses cpp to process Haskell files and that `\utarget` is the start of a lambda abstraction and not some weird unicode. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 07:00:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 07:00:39 -0000 Subject: [GHC] #10667: '-g' option generates invalid assembly when '*/*' operator is used In-Reply-To: <045.7de7e3e8915f886ced608adea09f7f67@haskell.org> References: <045.7de7e3e8915f886ced608adea09f7f67@haskell.org> Message-ID: <060.b041b1f69ae4260c5d4da796e90a83af@haskell.org> #10667: '-g' option generates invalid assembly when '*/*' operator is used -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2-rc2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by akio): * cc: akio (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 07:02:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 07:02:24 -0000 Subject: [GHC] #10444: Tex.Read.Lex.lex broken In-Reply-To: <048.7d303af6bd6af366785c1d3e315fce90@haskell.org> References: <048.7d303af6bd6af366785c1d3e315fce90@haskell.org> Message-ID: <063.de30e3a49c66d13dc30ed991b772b953@haskell.org> #10444: Tex.Read.Lex.lex broken -------------------------------------+------------------------------------- Reporter: strake888 | Owner: ekmett Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: | Phab:D1122. -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => Phab:D1122. Comment: I have opened Phab:D1122 to track an updated version of this patch. The refactoring of `GeneralCategory` is tracked in Phab:D1121. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 07:11:44 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 07:11:44 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.d06f8cf888e7d442f89437b78126d45d@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonmar): @bgamari, correct - ThreadScope won't tell us anything about the origin of blackholes, but it would confirm whether there is a lot of blocking on blackholes. Ideally we should see all the capabilities fully busy when compiling a perfectly parallel workload. Note that dependencies between modules reduce the amount of parallelism available in general, so for a good test it would be best to construct an example with plenty of parallelism. @slyfox, I don't believe perf is telling us anything sensible here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 08:47:41 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 08:47:41 -0000 Subject: [GHC] #10730: Spectral norm allocations increased 17% between 7.6 and 7.8 Message-ID: <046.f460604f62ed63bc6ffe6e4c6c723fa6@haskell.org> #10730: Spectral norm allocations increased 17% between 7.6 and 7.8 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- It appears that `spectral-norm` regressed rather severely from 7.6 to 7.8 in total allocations. Meanwhile the binary size also increased by 7% or so. However, it also appears that runtime was unaffected by this change. The rule firings are very similar between 7.6 and 7.8. Three rules fire in 786 that do not fire in 7.6, {{{ 1 Class op formatArg 1 Class op parseFormat 1 tagToEnum# }}} The difference in allocation persists even if one reverts the `Text.Printf` rewrite that gives rise to the `formatArg` and `parseFormat` rules, so these can be safely ignored. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 08:54:52 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 08:54:52 -0000 Subject: [GHC] #10722: GHC accepts "instance forall b. Blah []" In-Reply-To: <043.10dfce0f67b1d66985f02b8aa664359c@haskell.org> References: <043.10dfce0f67b1d66985f02b8aa664359c@haskell.org> Message-ID: <058.a01300f78836da7ed7eb838deb72eab8@haskell.org> #10722: GHC accepts "instance forall b. Blah []" -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: comment:1 isn't right: with `ScopedTypeVariables` the type variables mentioned the instance head are in scope in the instances (see [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/other- type-extensions.html#cls-inst-scoped-tyvars the manual]). Eg {{{ instance Eq a => Eq [a] where (==) (x:xs) (y:ys) = (x::a) == y) && (xs::[a] == ys) }}} should work just fine. You don't even need a forall. (I will add a note to say this.) However the variable `b` is unused in instance head, and there is really no point in having it there; hence the message. If you have a use-case where you want an instance to be quantified over a type that is not mentioned in the instance head, I'd be glad to see it. Meanwhile I'll mark this as invalid. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 09:15:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 09:15:04 -0000 Subject: [GHC] #10155: [PATCH] Possibly incorrect stack pointer usage in StgRun() on x86_64 In-Reply-To: <046.cfdb0dc1b2281b62f1e87667e0f4270a@haskell.org> References: <046.cfdb0dc1b2281b62f1e87667e0f4270a@haskell.org> Message-ID: <061.cc4bd1ca6cb058e49a6f86ae591d2c4c@haskell.org> #10155: [PATCH] Possibly incorrect stack pointer usage in StgRun() on x86_64 -------------------------------------+------------------------------------- Reporter: stengel | Owner: | thoughtpolice Type: bug | Status: patch Priority: high | Milestone: 7.12.1 Component: Runtime System | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b38ee89c8c8724ba2feb98d4082795a5d4ae96f6/ghc" b38ee89c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b38ee89c8c8724ba2feb98d4082795a5d4ae96f6" Fix incorrect stack pointer usage in StgRun() on x86_64 The STG_RETURN code from StgCRun.c is incorrect for x86_64 variants where the ABI doesn't impose a mandatory red zone for the stack, like on Windows or Xen/HaLVM. The current implementation restores the stack pointer first, which effectively marks the area with the saved registers as reusable. Later, the CPU registers are restored from this "free" area. This ordering happens to work by accident on operating systems that strictly adhere to the System V ABI, because any interrupt/signal delivery is guaranteed to leave the first 128 bytes past the stack pointer untouched (red zone). On other systems this might result in corrupted CPU registers if an interruption happens just after restoring the stack pointer. The red zone is usually only used by small leaf functions to avoid updates to the stack pointer and exploiting it doesn't give us any advantage in this case. Reviewers: austin, rwbarton Reviewed By: rwbarton Subscribers: thomie, simonmar Differential Revision: https://phabricator.haskell.org/D1120 GHC Trac Issues: #10155 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 09:15:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 09:15:04 -0000 Subject: [GHC] #9430: implement more arithmetic operations natively in the LLVM backend In-Reply-To: <047.5faa8daf1edcacef61c9001ac8b43152@haskell.org> References: <047.5faa8daf1edcacef61c9001ac8b43152@haskell.org> Message-ID: <062.4c2e9f1e3651dc25ec0fbc56b070b840@haskell.org> #9430: implement more arithmetic operations natively in the LLVM backend -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: michalt Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | primops/should_run/T9430 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"92f5385d8b2be50848a2496199a481f299f4b53a/ghc" 92f5385/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="92f5385d8b2be50848a2496199a481f299f4b53a" Support MO_U_QuotRem2 in LLVM backend This adds support for MO_U_QuotRem2 in LLVM backend. Similarly to MO_U_Mul2 we use the standard LLVM instructions (in this case 'udiv' and 'urem') but do the computation on double the word width (e.g., for 64-bit we will do them on 128 registers). Test Plan: validate Reviewers: rwbarton, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1100 GHC Trac Issues: #9430 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 09:50:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 09:50:17 -0000 Subject: [GHC] #10155: [PATCH] Possibly incorrect stack pointer usage in StgRun() on x86_64 In-Reply-To: <046.cfdb0dc1b2281b62f1e87667e0f4270a@haskell.org> References: <046.cfdb0dc1b2281b62f1e87667e0f4270a@haskell.org> Message-ID: <061.86f6bcf729feba86b7524ba98bb5c975@haskell.org> #10155: [PATCH] Possibly incorrect stack pointer usage in StgRun() on x86_64 -------------------------------------+------------------------------------- Reporter: stengel | Owner: | thoughtpolice Type: bug | Status: closed Priority: high | Milestone: 7.12.1 Component: Runtime System | Version: 7.8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 09:59:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 09:59:35 -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.e5f352216bbc8f8d40089646173c7467@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 7.12.1 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Yes, do rebase `wip/nested-cpr` on master, do a like-for-like `nofib` comparison. I'd quite like to see this land. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 10:24:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 10:24:22 -0000 Subject: [GHC] #9430: implement more arithmetic operations natively in the LLVM backend In-Reply-To: <047.5faa8daf1edcacef61c9001ac8b43152@haskell.org> References: <047.5faa8daf1edcacef61c9001ac8b43152@haskell.org> Message-ID: <062.e7ebca5e5d5278177ffd219a401d5951@haskell.org> #9430: implement more arithmetic operations natively in the LLVM backend -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: michalt Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | primops/should_run/T9430 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Here is the current state of things as I understand them. ||= MachOp =||= LLVM construct =||= commit =|| || MO_Add2 || @llvm.uadd.with.overflow.* || b1d1c652908ecd7bfcf13cf2e5dd06ac7926992c/ghc || || MO_AddIntC || @llvm.sadd.with.overflow.* || b1d1c652908ecd7bfcf13cf2e5dd06ac7926992c/ghc || || MO_SubIntC || @llvm.ssub.with.overflow.* || b1d1c652908ecd7bfcf13cf2e5dd06ac7926992c/ghc || || MO_U_Mul2 || mul i64/i128? || TODO || || MO_U_QuotRem2 || udiv i64/i128? || 92f5385d8b2be50848a2496199a481f299f4b53a/ghc || -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 11:10:36 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 11:10:36 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.0cc67cd2e60016f61ffe71ce88febf37@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.12.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Fanael): No, because Windows does not use ELF, so gold is completely useless there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 11:24:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 11:24:16 -0000 Subject: [GHC] #10444: Text.Read.Lex.lex broken (was: Tex.Read.Lex.lex broken) In-Reply-To: <048.7d303af6bd6af366785c1d3e315fce90@haskell.org> References: <048.7d303af6bd6af366785c1d3e315fce90@haskell.org> Message-ID: <063.5c6165beb8239d92e58068e7a3af93ec@haskell.org> #10444: Text.Read.Lex.lex broken -------------------------------------+------------------------------------- Reporter: strake888 | Owner: ekmett Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: | Phab:D1122. -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > {{{ > Prelude> lex "&) = mempty" > [("&",") = mempty")] > Prelude> lex "?) = mempty" > [] > }}} > > I traced this problem to Text.Read.Lex.lex New description: {{{ Prelude> lex "&) = mempty" [("&",") = mempty")] Prelude> lex "?) = mempty" [] }}} I traced this problem to Text.Read.Lex.lex -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 11:37:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 11:37:35 -0000 Subject: [GHC] #3306: Improve syntax for GADT + records In-Reply-To: <046.d67bbf39466d205ecf2349957e851ca2@haskell.org> References: <046.d67bbf39466d205ecf2349957e851ca2@haskell.org> Message-ID: <061.6ed30b0438e1cbce8e9223a2a21271ec@haskell.org> #3306: Improve syntax for GADT + records -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: feature request | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by skvadrik): * failure: => None/Unknown Comment: 6 years later: removed deprecated syntax for GADT constuctors. This allows to get rid of 2 reduce/reduce conflicts in parser. Conflicting productions were: {{{ gadt_constr -> con_list '::' sigtype gadt_constr -> oqtycon '{' fielddecls '}' '::' sigtype }}} Recursive inlining of con_list and oqtycon helped reveal the conflict: {{{ gadt_constr -> '(' CONSYM ')' '::' sigtype gadt_constr -> '(' CONSYM ')' '{' fielddecls '}' '::' sigtype }}} between two types of GADT constructors (second form stands for deprecated syntax). However, old syntax allowed `oqtycon` in constructor names, while new syntax allows `con` (which is not the same). There are therefore some constructor names that cannot be expressed in terms of new syntax (e.g. `(*)`). Note that ordinary data constructors are parsed in a different way than GADTs: types and names are mixed, so names have to be parsed as types and then converted to names. In GADTs constructor names and types are separated by `::`, so names can be parsed as just names and not as types. This results in a difference in the set of names allowed in GADT and ordinary constructors. See `Note [Parsing data constructors is hard]` and `Note [Difference in parsing GADT and data constructors]` Differential Revision: https://phabricator.haskell.org/D1118 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 12:08:12 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 12:08:12 -0000 Subject: [GHC] #10134: Pattern Matching Causes Infinite Type Error In-Reply-To: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> References: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> Message-ID: <060.67b329f72a95047a52a5ad480ce84769@haskell.org> #10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): `TypeFamilies` without `MonoLocalBinds` is an unsupported configuration. The user manual, section 7.13.9.3 (on let-generalization) concludes with this: > The flag `-XMonoLocalBinds` is implied by `-XTypeFamilies` and `-XGADTs`. You can switch it off again with `-XNoMonoLocalBinds` but type inference becomes less predicatable if you do so. (Read the papers!) So it seems this is clash's problem, after all, in setting a wonky configuration. I think this ticket can be closed as invalid, but one of the posters should double-check me before closing. Thanks, @thomie, for the analysis! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 12:26:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 12:26:23 -0000 Subject: [GHC] #10722: GHC accepts "instance forall b. Blah []" In-Reply-To: <043.10dfce0f67b1d66985f02b8aa664359c@haskell.org> References: <043.10dfce0f67b1d66985f02b8aa664359c@haskell.org> Message-ID: <058.65e2c50d18b8bd53352ea2f219591efa@haskell.org> #10722: GHC accepts "instance forall b. Blah []" -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"d7ced09a0a8d9e0f3c6631e2814078145036c90a/ghc" d7ced09a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d7ced09a0a8d9e0f3c6631e2814078145036c90a" Minor improvement to user guide Specify that the type variables for a class/instance decl scope over the body even without a 'forall'. Provoked by Trac #10722. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 12:39:43 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 12:39:43 -0000 Subject: [GHC] #10134: Pattern Matching Causes Infinite Type Error In-Reply-To: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> References: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> Message-ID: <060.a30c73c67536376daeceacf1f5927344@haskell.org> #10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Wonky or not, GHC ought to be able to solve `t0 ~ (t0 + 1) - 1`. And indeed it is fine with GHC 7.10 and HEAD. So I'll add this nicely-reduced test (thank you) as a regression test, and close the ticket. I hope that CLASH compiles ok with 7.10! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 12:40:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 12:40:02 -0000 Subject: [GHC] #10134: Pattern Matching Causes Infinite Type Error In-Reply-To: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> References: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> Message-ID: <060.e940ff616f5b3aa255d4e8739ec1e849@haskell.org> #10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T10134 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => polykinds/T10134 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 12:40:59 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 12:40:59 -0000 Subject: [GHC] #10134: Pattern Matching Causes Infinite Type Error In-Reply-To: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> References: <045.16fac11b22e89f55f2b7f03bdfbd5d14@haskell.org> Message-ID: <060.0feb4c99b996da927fd44fa737b8a7fa@haskell.org> #10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T10134 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"30b32f4ca83147544c4dafeb96fed70b791e40cd/ghc" 30b32f4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="30b32f4ca83147544c4dafeb96fed70b791e40cd" Test Trac #10134 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 12:42:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 12:42:17 -0000 Subject: [GHC] #10713: Type family not reducing over data family In-Reply-To: <046.5ef44ab91bf829939e28ffc1eb7fff9f@haskell.org> References: <046.5ef44ab91bf829939e28ffc1eb7fff9f@haskell.org> Message-ID: <061.d8db5b2b1926c7b3e8ef7c95151795bf@haskell.org> #10713: Type family not reducing over data family -------------------------------------+------------------------------------- Reporter: acowley | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.4 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire Comment: Good point. I know what is going on here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 12:54:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 12:54:50 -0000 Subject: [GHC] #9557: Deriving instances is slow In-Reply-To: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> References: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> Message-ID: <063.d6e0a1ffd40fb6a6e8380d65252de870@haskell.org> #9557: Deriving instances is slow -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8731 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Compile-time performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 12:56:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 12:56:17 -0000 Subject: [GHC] #9233: Compiler performance regression In-Reply-To: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> References: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> Message-ID: <062.dfb16ff9a727e2761bbfaac9500e7829@haskell.org> #9233: Compiler performance regression -------------------------------------+------------------------------------- Reporter: augustss | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D73 -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire Comment: I'm on it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 13:07:56 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 13:07:56 -0000 Subject: [GHC] #10664: T8131 times out on master In-Reply-To: <046.cb11813953cf382c76feac6f7fc0b89d@haskell.org> References: <046.cb11813953cf382c76feac6f7fc0b89d@haskell.org> Message-ID: <061.81847bb0e43f7e08182197b50b1691f8@haskell.org> #10664: T8131 times out on master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Hmm, it seems like some knot-typing in `FCode` may be going wrong. I've been chasing this down with the profiler and `-xc` and it appears that we're getting stuck in `StgCmmMonad.fixC`. It appears that the only user of this is `StgCmmExtCode.loopDecls`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 13:21:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 13:21:07 -0000 Subject: [GHC] #10664: T8131 times out on master In-Reply-To: <046.cb11813953cf382c76feac6f7fc0b89d@haskell.org> References: <046.cb11813953cf382c76feac6f7fc0b89d@haskell.org> Message-ID: <061.f0ef2acbd9274f3c3b1d61c06fe591c3@haskell.org> #10664: T8131 times out on master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): The issue appears to be triggered by the fourth argument of the `%memcpy` call being non-constant, {{{ // This fails testMemcpy (W_ dst, W_ src, W_ l, W_ sz) { prim %memcpy(dst, src, l, sz); return (); } // This also fails testMemcpy (W_ dst, W_ src, W_ l, W_ sz) { W_ a; a = 0; prim %memcpy(dst, src, l, a); return (); } // But this succeeds testMemcpy (W_ dst, W_ src, W_ l, W_ sz) { prim %memcpy(dst, src, l, 0); return (); } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 13:28:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 13:28:15 -0000 Subject: [GHC] #10664: T8131 times out on master In-Reply-To: <046.cb11813953cf382c76feac6f7fc0b89d@haskell.org> References: <046.cb11813953cf382c76feac6f7fc0b89d@haskell.org> Message-ID: <061.0f4009bc1e7e5fa1ab61d6fc5af0ffaa@haskell.org> #10664: T8131 times out on master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): It appears that this is due to a rework I made for the LLVM backend, 681973c31c614185229bdae4f6b7ab4f6e64753d. Here I explicitly forced the alignment argument to `%memcpy` calls to ensure that `pprPgmError` fired. I did this as otherwise the should-fail test I introduced to test the feature would fail in the case of the NCG (which apparently sometimes never forces the alignment). Admittedly this was a bit of a large hammer to just make some tests pass. I'm going to remove the `seq` and just only run the test against the LLVM backend. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 13:34:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 13:34:09 -0000 Subject: [GHC] #10664: T8131 times out on master In-Reply-To: <046.cb11813953cf382c76feac6f7fc0b89d@haskell.org> References: <046.cb11813953cf382c76feac6f7fc0b89d@haskell.org> Message-ID: <061.fac16b7c380aa8a7353bb2134caafc3a@haskell.org> #10664: T8131 times out on master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 13:36:36 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 13:36:36 -0000 Subject: [GHC] #10586: GHC 7.10.1 panic due to wildcard in data family instance In-Reply-To: <051.1ad24f379aa873ec60f60cfdaf86ad2c@haskell.org> References: <051.1ad24f379aa873ec60f60cfdaf86ad2c@haskell.org> Message-ID: <066.1da5b4ffb6780f0d252fbccd126fd542@haskell.org> #10586: GHC 7.10.1 panic due to wildcard in data family instance -------------------------------------+------------------------------------- Reporter: WrenThornton | Owner: thomasw Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3699 | Differential Revisions: Phab:D1092 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d9d2102ea7f6da1bc3a69fa469b89ea843cb8b02/ghc" d9d2102e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d9d2102ea7f6da1bc3a69fa469b89ea843cb8b02" Support wild cards in data/type family instances Handle anonymous wild cards in type or data family instance declarations like unnamed type variables. For instance (pun intented): type family F (a :: *) (b :: *) :: * type instance F Int _ = Int Is now the same as: type family F (a :: *) (b :: *) :: * type instance F Int x = Int Note that unlike wild cards in partial type signatures, no errors (or warnings with -XPartialTypeSignatures) are generated for these wild cards, as there is nothing interesting to report to the user, i.e. the inferred kind. Only anonymous wild cards are supported here, named and extra-constraints wild card are not. Test Plan: pass new tests Reviewers: goldfire, austin, simonpj, bgamari Reviewed By: simonpj, bgamari Subscribers: goldfire, thomie Differential Revision: https://phabricator.haskell.org/D1092 GHC Trac Issues: #3699, #10586 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 13:36:36 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 13:36:36 -0000 Subject: [GHC] #3699: Wildcards in type functions In-Reply-To: <060.b01af1dc1c462193a392550aa45e1d6c@haskell.org> References: <060.b01af1dc1c462193a392550aa45e1d6c@haskell.org> Message-ID: <075.3e324404d66189270f1593229d99a682@haskell.org> #3699: Wildcards in type functions -------------------------------------+------------------------------------- Reporter: | Owner: msosn MartijnVanSteenbergen | Type: feature request | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler (Type | Version: 6.10.4 checker) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1092 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d9d2102ea7f6da1bc3a69fa469b89ea843cb8b02/ghc" d9d2102e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d9d2102ea7f6da1bc3a69fa469b89ea843cb8b02" Support wild cards in data/type family instances Handle anonymous wild cards in type or data family instance declarations like unnamed type variables. For instance (pun intented): type family F (a :: *) (b :: *) :: * type instance F Int _ = Int Is now the same as: type family F (a :: *) (b :: *) :: * type instance F Int x = Int Note that unlike wild cards in partial type signatures, no errors (or warnings with -XPartialTypeSignatures) are generated for these wild cards, as there is nothing interesting to report to the user, i.e. the inferred kind. Only anonymous wild cards are supported here, named and extra-constraints wild card are not. Test Plan: pass new tests Reviewers: goldfire, austin, simonpj, bgamari Reviewed By: simonpj, bgamari Subscribers: goldfire, thomie Differential Revision: https://phabricator.haskell.org/D1092 GHC Trac Issues: #3699, #10586 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 13:58:59 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 13:58:59 -0000 Subject: [GHC] #10586: GHC 7.10.1 panic due to wildcard in data family instance In-Reply-To: <051.1ad24f379aa873ec60f60cfdaf86ad2c@haskell.org> References: <051.1ad24f379aa873ec60f60cfdaf86ad2c@haskell.org> Message-ID: <066.40f061c6b6daea651d8fc618799a8023@haskell.org> #10586: GHC 7.10.1 panic due to wildcard in data family instance -------------------------------------+------------------------------------- Reporter: WrenThornton | Owner: thomasw Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3699 | Differential Revisions: Phab:D1092 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 13:59:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 13:59:15 -0000 Subject: [GHC] #3699: Wildcards in type functions In-Reply-To: <060.b01af1dc1c462193a392550aa45e1d6c@haskell.org> References: <060.b01af1dc1c462193a392550aa45e1d6c@haskell.org> Message-ID: <075.7bab05ca6fd7bcccc72ea709d6441a43@haskell.org> #3699: Wildcards in type functions -------------------------------------+------------------------------------- Reporter: | Owner: msosn MartijnVanSteenbergen | Type: feature request | Status: closed Priority: low | Milestone: 7.12.1 Component: Compiler (Type | Version: 6.10.4 checker) | Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1092 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 14:54:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 14:54:50 -0000 Subject: [GHC] #10708: Rejection of constant functions defined using conditional pattern matching In-Reply-To: <052.6642c2a30fffd04ac1211d679c9e5063@haskell.org> References: <052.6642c2a30fffd04ac1211d679c9e5063@haskell.org> Message-ID: <067.567fb2385896d95de7cdb39f190324ff@haskell.org> #10708: Rejection of constant functions defined using conditional pattern matching -------------------------------------+------------------------------------- Reporter: HubertGaravel | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: closed => new * type: bug => feature request * resolution: invalid => * os: Linux => Unknown/Multiple * architecture: x86 => Unknown/Multiple Comment: I find comment:5 compelling. But is it worth implementing, and invariably adding a new language flag? I'm not sure, but I'm turning this back around into a feature request. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 15:01:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 15:01:47 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.c24e129c6c71e96e8c159fbe32391381@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: 8317 Related Tickets: #1498 | Differential Revisions: Phab:D343 -------------------------------------+------------------------------------- Comment (by simonpj): Why this ticket #8326 is blocking #8317? I think precisely this: implementing #8317 on its own causes a 2.5% code size increase. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 15:16:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 15:16:27 -0000 Subject: [GHC] #9430: implement more arithmetic operations natively in the LLVM backend In-Reply-To: <047.5faa8daf1edcacef61c9001ac8b43152@haskell.org> References: <047.5faa8daf1edcacef61c9001ac8b43152@haskell.org> Message-ID: <062.16dafb39007360e3825f72adb61847fe@haskell.org> #9430: implement more arithmetic operations natively in the LLVM backend -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: michalt Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | primops/should_run/T9430 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): But MO_U_Mul2 was done in 82ffc80d (comment:9) right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 15:21:00 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 15:21:00 -0000 Subject: [GHC] #10664: T8131 times out on master In-Reply-To: <046.cb11813953cf382c76feac6f7fc0b89d@haskell.org> References: <046.cb11813953cf382c76feac6f7fc0b89d@haskell.org> Message-ID: <061.3e40e4ab601134436e71addd18fa4b78@haskell.org> #10664: T8131 times out on master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"64b6733e217f32feb8c4872096749c6f417d0c39/ghc" 64b6733e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="64b6733e217f32feb8c4872096749c6f417d0c39" CmmParse: Don't force alignment in memcpy-ish operations This was initially made in 681973c31c614185229bdae4f6b7ab4f6e64753d. Here I wanted to enforce that the alignment passed to %memcpy was a constant expression, as this is required by LLVM. However, this breaks the knot-tying done in `loopDecls`, causing T8131 to hang. Here I remove the `seq` and mark T8131 as `expect_broken` in the case of the NCG, which doesn't force the alignment in this case. Fixes #10664. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 15:30:28 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 15:30:28 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.95f3b68a5a5320f1d3f268cf374de670@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * cc: scpmw (added) Comment: @scpmw, would it be possible to identify the expressions being blackholed (assuming that is indeed what is happening here) from `perf`'s output? It seems like this might be a good use-case for our new DWARF support if so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 15:35:32 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 15:35:32 -0000 Subject: [GHC] #10723: Make declarations in signatures "weakly bound" until they are used In-Reply-To: <045.468e4f2d1d9f6be5dd513d2c8bb6c010@haskell.org> References: <045.468e4f2d1d9f6be5dd513d2c8bb6c010@haskell.org> Message-ID: <060.fffac0e363c10987a6b607451b00e712@haskell.org> #10723: Make declarations in signatures "weakly bound" until they are used -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.11 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by skilpat): * cc: skilpat (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 16:09:56 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 16:09:56 -0000 Subject: [GHC] #10711: Defining mapM_ in terms of traverse_ causes substantial blow-up in ByteCodeAsm In-Reply-To: <046.926df7dc33b426cbfee9f2a989a5cdc6@haskell.org> References: <046.926df7dc33b426cbfee9f2a989a5cdc6@haskell.org> Message-ID: <061.252987eaf0ecc76b3cdb71dc1408ede2@haskell.org> #10711: Defining mapM_ in terms of traverse_ causes substantial blow-up in ByteCodeAsm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: ghcirun004 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * cc: core-libraries-committee@? (added) * status: new => closed * resolution: => fixed Comment: Thanks akio for the analysis! It seems pretty clear that rewriting `mapM_` in terms of `traverse_` does not preserve the performance characteristics of user code in general. I'm going to close this and push the matter off to the Core Libraries Committee to decide what implications this might have on their future plans (likely few given they already [https://mail.haskell.org/pipermail/libraries/2015-May/025719.html suspected] there was the potential for performance regressions with this change). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 16:10:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 16:10:22 -0000 Subject: [GHC] #10711: Defining mapM_ in terms of traverse_ causes substantial blow-up in ByteCodeAsm In-Reply-To: <046.926df7dc33b426cbfee9f2a989a5cdc6@haskell.org> References: <046.926df7dc33b426cbfee9f2a989a5cdc6@haskell.org> Message-ID: <061.8326b793c08075108d1bbbb3228ccf19@haskell.org> #10711: Defining mapM_ in terms of traverse_ causes substantial blow-up in ByteCodeAsm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: ghcirun004 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * owner: bgamari => * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 16:10:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 16:10:35 -0000 Subject: [GHC] #10711: Defining mapM_ in terms of traverse_ causes substantial blow-up in ByteCodeAsm In-Reply-To: <046.926df7dc33b426cbfee9f2a989a5cdc6@haskell.org> References: <046.926df7dc33b426cbfee9f2a989a5cdc6@haskell.org> Message-ID: <061.f859ae08efa2a9ef00c11c668031c8dc@haskell.org> #10711: Defining mapM_ in terms of traverse_ causes substantial blow-up in ByteCodeAsm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: ghcirun004 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 16:17:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 16:17:06 -0000 Subject: [GHC] #10723: Make declarations in signatures "weakly bound" until they are used In-Reply-To: <045.468e4f2d1d9f6be5dd513d2c8bb6c010@haskell.org> References: <045.468e4f2d1d9f6be5dd513d2c8bb6c010@haskell.org> Message-ID: <060.08d75a4c0c5d2dc097ff870301a2776a@haskell.org> #10723: Make declarations in signatures "weakly bound" until they are used -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.11 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by skilpat): The use case you have in mind (which is a good one) sounds exactly like one of the motivations for thinning in Paper Backpack. The idea is that clients could include only the portion of a larger "signature package" that they actually use: {{{ -- using the syntax of the POPL paper package containers-sig-3 where include prelude-sig-1 Data.Set :: [...] Data.Tree :: [...] Data.Graph :: [...] package client where include prelude-sig-1 include containers-sig-3(Data.Set) M = [import Data.Set; ...] }}} The result is that `client` has holes for the prelude stuff and for `Data.Set`, but not for `Data.Tree` or `Data.Graph` -- assuming `Data.Set` doesn't actually make use of (i.e. import) the latter two. So if there's a new version of `containers-sig-3` that makes BC-incompatible changes to `Data.Graph`, then `client` is totally unaffected and will link against an implementation of either version of containers. A problem with thinning is that it's highly dependent on the import graph of the signature package, which isn't a very good signal to clients what kinds of feature selection they can employ in using that signature package. But the nice thing is that it allows ex post facto selection of signature subpackages, so to speak, after the original author has already set it in stone. Anyway, back to the proposal at hand. It seems feasible to me so long as the usage info is used for warnings rather than for implicitly "thinning" a signature package; in other words, so long as it's employed explicitly rather than implicitly. For example, the usage info about `containers- sig-3` could enable a warning that says "you included `containers-sig-3` but didn't use some modules; do you want to annotate the include?". Instead, if the usage info enabled the client package to only (syntactically) depend on `Data.Set` despite no such annotation, that would feel kinda weird IMO. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 16:19:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 16:19:15 -0000 Subject: [GHC] #10457: Revise/remove custom mapM implementation for lists In-Reply-To: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> References: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> Message-ID: <059.f683af516bf2b1c574761c2c44b6aba9@haskell.org> #10457: Revise/remove custom mapM implementation for lists -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.12.1 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1124 -------------------------------------+------------------------------------- Changes (by bgamari): * differential: Phab:D924 => Phab:D1124 Old description: > Recently, Simon Marlow asked why the list instance for Traversable had a > custom mapM implementation that used the Monad operations. Having looked > a bit, I don't think there's any good reason. The only fusion that the > custom mapM can participate in is due to it being written as foldr, but > traverse is, as well. So as long as 'mapM = traverse' is able to inline > appropriately, there should be no difference. > > Further, this can be changed, in principle, for 7.10.2. It doesn't change > any types, only the implementation. > > mapM = traverse is the class default definition, so this could possibly > be completed by just removing the custom definition. > > Link to the libraries thread: > https://mail.haskell.org/pipermail/libraries/2015-May/025708.html New description: Recently, Simon Marlow asked why the list instance for `Traversable` had a custom `mapM` implementation that used the `Monad` operations. Having looked a bit, I don't think there's any good reason. The only fusion that the custom `mapM` can participate in is due to it being written as `foldr`, but `traverse` is, as well. So as long as `mapM = traverse` is able to inline appropriately, there should be no difference. Further, this can be changed, in principle, for 7.10.2. It doesn't change any types, only the implementation. `mapM = traverse` is the class default definition, so this could possibly be completed by just removing the custom definition. Link to the libraries thread: https://mail.haskell.org/pipermail/libraries/2015-May/025708.html -- Comment: Phab:D924 proposed a redefinition of `mapM_` in addition to the removal of list's override of `mapM`. This changed the performance characteristics of user code, as seen in #10711. I've extracted the removal of the `mapM` override into Phab:D1124 and forwarded the `mapM_` issue to the Core Libraries Committee. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 16:20:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 16:20:22 -0000 Subject: [GHC] #3306: Improve syntax for GADT + records In-Reply-To: <046.d67bbf39466d205ecf2349957e851ca2@haskell.org> References: <046.d67bbf39466d205ecf2349957e851ca2@haskell.org> Message-ID: <061.bf651b3dfeff6bc2f48b3fae2f74533d@haskell.org> #3306: Improve syntax for GADT + records -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: feature request | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"30c981e135033840fe1b4bcab697b412369739d7/ghc" 30c981e1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="30c981e135033840fe1b4bcab697b412369739d7" Removed deprecated syntax for GADT constuctors. Old syntax was deprecated 6 years ago in this commit 432b9c9322181a3644083e3c19b7e240d90659e7 by simonpj:"New syntax for GADT-style record declarations, and associated refactoring" discussed in Trac #3306. This patch removes 2 reduce/reduce conflicts in parser. Conflicting productions were: ``` gadt_constr -> con_list '::' sigtype gadt_constr -> oqtycon '{' fielddecls '}' '::' sigtype ``` Recursive inlining of `con_list` and `oqtycon` helped reveal the conflict: ``` gadt_constr -> '(' CONSYM ')' '::' sigtype gadt_constr -> '(' CONSYM ')' '{' fielddecls '}' '::' sigtype ``` between two types of GADT constructors (second form stands for deprecated syntax). Test Plan: `make fasttest`, one breakage TEST="records-fail" (parse error instead of typecheck error due to removal of deprecated syntax). Updated test. Reviewers: simonmar, bgamari, austin, simonpj Reviewed By: simonpj Subscribers: thomie, mpickering, trofi Differential Revision: https://phabricator.haskell.org/D1118 GHC Trac Issues: #3306 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 16:33:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 16:33:03 -0000 Subject: [GHC] #10664: T8131 times out on master In-Reply-To: <046.cb11813953cf382c76feac6f7fc0b89d@haskell.org> References: <046.cb11813953cf382c76feac6f7fc0b89d@haskell.org> Message-ID: <061.cd785a9c99c44bfb7520a995319cf57a@haskell.org> #10664: T8131 times out on master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 16:42:44 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 16:42:44 -0000 Subject: [GHC] #10730: Spectral norm allocations increased 17% between 7.6 and 7.8 In-Reply-To: <046.f460604f62ed63bc6ffe6e4c6c723fa6@haskell.org> References: <046.f460604f62ed63bc6ffe6e4c6c723fa6@haskell.org> Message-ID: <061.24cfac99fd79485cde554d3746a1d36b@haskell.org> #10730: Spectral norm allocations increased 17% between 7.6 and 7.8 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > It appears that `spectral-norm` regressed rather severely from 7.6 to 7.8 > in total allocations. Meanwhile the binary size also increased by 7% or > so. However, it also appears that runtime was unaffected by this change. > > The rule firings are very similar between 7.6 and 7.8. Three rules fire > in 786 that do not fire in 7.6, > {{{ > 1 Class op formatArg > 1 Class op parseFormat > 1 tagToEnum# > }}} > > The difference in allocation persists even if one reverts the > `Text.Printf` rewrite that gives rise to the `formatArg` and > `parseFormat` rules, so these can be safely ignored. New description: It appears that `spectral-norm` regressed rather severely from 7.6 to 7.8 in total allocations. Meanwhile the binary size also increased by 7% or so. However, it also appears that runtime was unaffected by this change. The rule firings are very similar between 7.6 and 7.8. Three rules fire in 7.8 that do not fire in 7.6, {{{ 1 Class op formatArg 1 Class op parseFormat 1 tagToEnum# }}} The difference in allocation persists even if one reverts the `Text.Printf` rewrite that gives rise to the `formatArg` and `parseFormat` rules, so these can be safely ignored. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 16:43:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 16:43:29 -0000 Subject: [GHC] #7679: Regression in -fregs-graph performance In-Reply-To: <047.9e26897513125de7441d596a4b30ee54@haskell.org> References: <047.9e26897513125de7441d596a4b30ee54@haskell.org> Message-ID: <062.be8bd5abb5ac1add2c127e27d9f86e10@haskell.org> #7679: Regression in -fregs-graph performance -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler (NCG) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7192, #8657 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * priority: high => low Comment: After discussing this with Simon Marlow we are going to drop this in severity as the gains offered by `-fregs-graph` weren't so great. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 18:25:32 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 18:25:32 -0000 Subject: [GHC] #10726: Upgrade MingW-w64 distributions for windows In-Reply-To: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> References: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> Message-ID: <059.e18a25381f7c58f88091397f98706d51@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: patch Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #9014 | Differential Revisions: Phab:D1123 #10435 | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 18:31:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 18:31:03 -0000 Subject: [GHC] #10723: Make declarations in signatures "weakly bound" until they are used In-Reply-To: <045.468e4f2d1d9f6be5dd513d2c8bb6c010@haskell.org> References: <045.468e4f2d1d9f6be5dd513d2c8bb6c010@haskell.org> Message-ID: <060.bb07ee09b29eb91c14f165bbf60a3d92@haskell.org> #10723: Make declarations in signatures "weakly bound" until they are used -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.11 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): It is hard to say what will actually happen in practice until we have people actually using backpack, but I suspect that thinning only at the module level won't be enough. There are two reasons: 1. Think about the average Haskell module: it contains a lot of functions! This means that the normal signature someone will write for a module that already exists is going to have a lot of functions. Here, thinning at the expression level seems more important. 2. How are people going to write signatures? I think that for library level signatures, the best use of peoples time is for signatures to automatically be inferred from existing implementations rather than forcing people to write signatures all the time. So a signature will in general contain way too much stuff! Thinning definitely is necessary in this case. The benefit of implicit thinning is that, although it is strange from a language design perspective, it makes a lot of sense intuitively: there is no dependence on the import graph: a units requirements are completely specified as the set of requirements that it uses, and the set of requirements it available to includers. Yes, it is not syntactically evident what this is, but the whole point of a compiler is that you can get it to tell you what it is (eg some sort of Haddock documentation. Where as with thinning, sometimes it is not permissible to thin a requirement depending on whether it was imported by a module. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 20:53:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 20:53:37 -0000 Subject: [GHC] #10731: System.IO.openTempFile is not thread safe on Windows Message-ID: <051.f6b2ae5c769c1cac9a336c0052f78eb7@haskell.org> #10731: System.IO.openTempFile is not thread safe on Windows -------------------------------------+------------------------------------- Reporter: | Owner: NeilMitchell | Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.1 libraries/base | Keywords: | Operating System: Windows Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Given the test program: {{{#!hs import Control.Concurrent import System.IO import Control.Monad import System.Directory main = do putStrLn "Starting" var <- newEmptyMVar tdir <- getTemporaryDirectory xs <- replicateM 10 $ do var <- newEmptyMVar flip forkFinally (\s -> do print s; putMVar var ()) $ do replicateM_ 100000 $ do (file, h) <- openTempFile tdir "test.txt" hClose h removeFile file return var mapM_ takeMVar xs }}} If I compile and run that with {{{ghc --make TmpFile.hs -threaded && tmpfile +RTS -N5}}} I get: {{{ Starting Left C:\Users\NDMIT_~1\AppData\Local\Temp\: openTempFile: permission denied (Permission denied) Left C:\Users\NDMIT_~1\AppData\Local\Temp\: openTempFile: permission denied (Permission denied) ... }}} I've reproduced this on GHC 7.8 and 7.10.1. We hit this in production about twice a day. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 20:57:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 20:57:17 -0000 Subject: [GHC] #10731: System.IO.openTempFile is not thread safe on Windows In-Reply-To: <051.f6b2ae5c769c1cac9a336c0052f78eb7@haskell.org> References: <051.f6b2ae5c769c1cac9a336c0052f78eb7@haskell.org> Message-ID: <066.cb4cbaca1c9f9442f0e16521560572f4@haskell.org> #10731: System.IO.openTempFile is not thread safe on Windows -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by NeilMitchell): Note that the exceptions start happening within seconds - this doesn't seem to be a difficult race condition to hit. I'm on Windows 8.1, but it reproduces just as easily with Windows 7. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 21:16:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 21:16:46 -0000 Subject: [GHC] #10528: compile time performance regression with OverloadedStrings and Text In-Reply-To: <048.98ab82d16d4bd14b388cfa4fc2b927d4@haskell.org> References: <048.98ab82d16d4bd14b388cfa4fc2b927d4@haskell.org> Message-ID: <063.e83713d8fdb6bb70eae05b706ec7ef3b@haskell.org> #10528: compile time performance regression with OverloadedStrings and Text -------------------------------------+------------------------------------- Reporter: jakewheat | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by afarmer): Please do merge the commit referenced in comment:15! HERMIT (for better or worse) still relies on rules pragmas to specify equational properties. The "fix huge space leak" commit mentioned in comment:12 effectively prevents us from using HERMIT with 7.10.2 because the left-hand sides of rules are being rewritten before they get to HERMIT. (Apologies for not spotting this earlier... I've been traveling this summer.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 21:31:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 21:31:17 -0000 Subject: [GHC] #10724: ghci crashing when using copy/paste in Gnome Terminal on Debian Jessie In-Reply-To: <048.3d43e86871e2f47f3491fb5fe466e924@haskell.org> References: <048.3d43e86871e2f47f3491fb5fe466e924@haskell.org> Message-ID: <063.d4710f8e3107bb9350eeb1bbe9392590@haskell.org> #10724: ghci crashing when using copy/paste in Gnome Terminal on Debian Jessie -------------------------------+----------------------------------------- Reporter: martinvlk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #3656 | Differential Revisions: -------------------------------+----------------------------------------- Comment (by rwbarton): > When I copy/paste text from a ghci instance running in the terminal, Can you be more specific? What exact key presses or mouse clicks do you use to copy/paste? Do you have a way to reliably reproduce the behavior? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 23:42:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 23:42:20 -0000 Subject: [GHC] #10732: Legal Bang Patterns cannot parse Message-ID: <042.4ad4dd039de0d1dea0d83f39e9f13584@haskell.org> #10732: Legal Bang Patterns cannot parse -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Parser) | Keywords: Bang | Operating System: Unknown/Multiple Pattern Parser | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- According to the syntax provided by GHC user guide pat ::= !pat Both !!pat and pat : !pat should be accepted, but GHC gives parsing error. For detail see http://stackoverflow.com/questions/31790327/where-can- bangpatterns-appear -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 3 23:46:36 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Aug 2015 23:46:36 -0000 Subject: [GHC] #10732: Legal Bang Patterns cannot parse In-Reply-To: <042.4ad4dd039de0d1dea0d83f39e9f13584@haskell.org> References: <042.4ad4dd039de0d1dea0d83f39e9f13584@haskell.org> Message-ID: <057.2f2f562b3f774f23784579f34366e55a@haskell.org> #10732: Legal Bang Patterns cannot parse -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Parser) | Keywords: Bang Resolution: | Pattern Parser Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by rem: Old description: > According to the syntax provided by GHC user guide > > pat ::= !pat > > Both !!pat and pat : !pat should be accepted, but GHC gives parsing > error. For detail see http://stackoverflow.com/questions/31790327/where- > can-bangpatterns-appear New description: According to the syntax provided by GHC user guide pat ::= !pat Both !!pat and pat : !pat should be accepted, but GHC gives parsing error. For detail see http://stackoverflow.com/questions/31790327/where-can- bangpatterns-appear There also lacks a formal documentation regarding where BangPatterns can appear (the User Guide mentions in passing that "a pattern with a bang at the outermost level is not allowed at the top level of a module." Are there other restrictions?) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 01:02:14 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 01:02:14 -0000 Subject: [GHC] #10733: Improving the error message for type variable ambiguity Message-ID: <049.e68ae3d7f8aaef94b3cdeb692d3e5ac5@haskell.org> #10733: Improving the error message for type variable ambiguity -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- This is a summary of a [https://mail.haskell.org/pipermail/ghc- devs/2015-August/009522.html discussion on ghc-devs]. The current message when a type variable is ambiguous could use a little rewording to improve its friendliness towards the user. Currently, it looks like this: {{{ No instance for (Foldable t0) arising from a use of ?elem? The type variable ?t0? is ambiguous Relevant bindings include valid :: t0 Char (bound at ?) Note: there are several potential instances: instance Foldable (Either a) -- Defined in ?Data.Foldable? instance Foldable Data.Proxy.Proxy -- Defined in ?Data.Foldable? instance GHC.Arr.Ix i => Foldable (GHC.Arr.Array i) -- Defined in ?Data.Foldable? ...plus three others }}} The focus seems to be on "No instance", which, while technically correct, does not usually lead to the correct solution of the problem. In particular, the "type variable is ambiguous" does not appear until the 2nd or 3rd line, making it easy to miss, which may lead to confusion with other kinds of "No instance" errors that have a similar leading sentence. There are two ways to fix this error usually: * By defining `instance Foldable t0`, but this is rarely what the user wants. * By fixing the ambiguity using a type annotation. Given that the latter seems to be a more likely cause, it may help if the error message were rewritten to prioritize that, while also leaving the first solution open if the user really knows what they are doing. Therefore, it is suggested that the message should reword in a way similar to this: {{{ Ambiguous type variable ?t0? arising from a use of ?elem? caused by the lack of an instance ?(Foldable t0)? Relevant bindings include valid :: t0 Char (bound at ?) Either use a type annotation to specify what ?t0? should be based on these potential instance(s): instance Foldable (Either a) -- Defined in ?Data.Foldable? instance Foldable Data.Proxy.Proxy -- Defined in ?Data.Foldable? instance GHC.Arr.Ix i => Foldable (GHC.Arr.Array i) ... plus three others and possibly more from other modules that the compiler has not yet encountered or define the required instance ?(Foldable t0)? }}} which puts the emphasis on "ambiguous type variable" in the first few words while also outlining the possible solutions for the user and reminding them of the open-world assumption. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 02:04:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 02:04:43 -0000 Subject: [GHC] #10528: compile time performance regression with OverloadedStrings and Text In-Reply-To: <048.98ab82d16d4bd14b388cfa4fc2b927d4@haskell.org> References: <048.98ab82d16d4bd14b388cfa4fc2b927d4@haskell.org> Message-ID: <063.2fd6ca9dc61c486ad81aa81fff37be22@haskell.org> #10528: compile time performance regression with OverloadedStrings and Text -------------------------------------+------------------------------------- Reporter: jakewheat | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 02:21:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 02:21:40 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.32ea557f95779b3f7d4cba7834dbdc8d@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * cc: rwbarton (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 03:05:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 03:05:24 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.0f1fb89d9bed33f71037046d197def32@haskell.org> #10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10059 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by RyanGlScott): What exactly ''should'' the precedence of `(~)` be, anyway? It definitely seems like it should be lower than most things, but how low? For example, should this: {{{#!hs f :: (Int -> Int ~ Int -> Int) => String }}} parse as this? {{{#!hs f :: ((Int -> Int) ~ (Int -> Int)) => String }}} Also, I'm not sure that I understand this concern: > Should `(~)` be imported as part of the Prelude? If no, then a lot of code breaks. If yes, that implies that hiding the `Prelude` also hides `(~)`, breaking less code, but still breaking code. Does hiding `Prelude` necessarily mean that `(~)` won't be visible? I was under the impression that certain types would still be visible even if `Prelude` was hidden, e.g., `(->)`. Couldn't we make `(~)` another such type and sidestep that issue? As for the `LANGUAGE` pragma question, I think it would make sense for `TypeOperators` to enable use of `(~)`. I would keep `TypeFamilies` and `GADTs`' ability to enable use of `(~)` to avoid breaking code unnecessarily?perhaps a warning can be emitted if `(~)` is used in the presence of `TypeFamilies` or `GADTs` but not `TypeOperators`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 04:24:47 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 04:24:47 -0000 Subject: [GHC] #10678: integer-gmp's runS seems unnecessarily expensive In-Reply-To: <047.1e3027d49179affc6473e88cc8dec51a@haskell.org> References: <047.1e3027d49179affc6473e88cc8dec51a@haskell.org> Message-ID: <062.d5a34526b5de9716952f6fd55cb52860@haskell.org> #10678: integer-gmp's runS seems unnecessarily expensive -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * Attachment "runRW-nofib.txt" added. nofib results -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 04:46:52 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 04:46:52 -0000 Subject: [GHC] #10678: integer-gmp's runS seems unnecessarily expensive In-Reply-To: <047.1e3027d49179affc6473e88cc8dec51a@haskell.org> References: <047.1e3027d49179affc6473e88cc8dec51a@haskell.org> Message-ID: <062.01dbb2b7657389e059d332697f376bae@haskell.org> #10678: integer-gmp's runS seems unnecessarily expensive -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): With #10694 fixed I am pretty happy with the results so far. Allocations are down for Integer and ByteString users as expected. Module size, compile allocations and compile time are also slightly down on average. The variation in program runtime seems to be due to a combination of noise and #8279. I suspect real world modern Haskell programs may gain more on average due to preferring ByteString and Text over String. The only programs in nofib which use ByteString (none use Text) are three shootout programs that have been highly optimized by hand. Maybe I should try fibon? For a microbenchmark {{{ f :: B.ByteString -> B.ByteString f s = case B.uncons s of Just (c, s') -> B.snoc s' c Nothing -> B.empty }}} allocations are down from 136 bytes to 96 bytes and runtime from 16ns to 13ns (when `s` is a 9-byte string). I got roughly similar results from an integer-gmp benchmark (repeatedly adding 1 to a large Integer). There is more room for improvement, though. Both these microbenchmarks allocate a boxed heap value inside the `runRW#`, only to immediately unbox it outside the `runRW#`. Some kind of CPR analysis + w/w-type transformation could eliminate these intermediate allocations. I implemented this transformation manually in bytestring and it shaved off another 40 bytes of allocation (indeed the size of a `ByteString` heap object) and ~10% of the runtime. However it would be much nicer for GHC to do this automatically. Need to think more on the best way to accomplish this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 05:05:20 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 05:05:20 -0000 Subject: [GHC] #10528: compile time performance regression with OverloadedStrings and Text In-Reply-To: <048.98ab82d16d4bd14b388cfa4fc2b927d4@haskell.org> References: <048.98ab82d16d4bd14b388cfa4fc2b927d4@haskell.org> Message-ID: <063.09f23c90d98bb5e8f5f3fc750be08d99@haskell.org> #10528: compile time performance regression with OverloadedStrings and Text -------------------------------------+------------------------------------- Reporter: jakewheat | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by afarmer): I cherry-picked bc4b64ca5b99bff6b3d5051b57cb2bc52bd4c841 onto the 7.10.2 release branch and built it to test HERMIT. It does fix the problem we were having with the LHS of rules being altered by the simplifier, which is good. However, the inlining/rule application still appears to be happening in the RHS of the rules, which wasn't expected. Looking at the patch, I see the simplifier environment for the RHS still allows inlining/rule application. Can we change the simplification of the RHS to also not inline/apply rules? (I'm happy to submit a patch that does this.) I assume doing so in the RHS saves redundant simplifier work, but (even outside HERMIT's use) the unexpected RHSs make it difficult to glue together rules into rewrite systems. For instance, given the following dummy rule set: {{{#!hs "foo" forall x. foo x = bar (baz x) "baz-quux" forall y. baz (quux y) = norf y }}} If this expression appeared: {{{#!hs foo (quux z) }}} I would expect it to be rewritten to: {{{#!hs bar (baz (quux z)) }}} then: {{{#!hs bar (norf z) }}} But, if `baz` is inlined in the RHS of rule "foo", then rule "baz-quux" may never get to fire on the result of "foo" applications. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 05:23:17 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 05:23:17 -0000 Subject: [GHC] #10676: silly assembly for comparing the result of comparisons that return Int# against 0# In-Reply-To: <047.c9f81303ccca01d21593f2a37d62e3ce@haskell.org> References: <047.c9f81303ccca01d21593f2a37d62e3ce@haskell.org> Message-ID: <062.78b26a4571c4a01220238bc79178ccf2@haskell.org> #10676: silly assembly for comparing the result of comparisons that return Int# against 0# -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (CodeGen) | Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8326, #8327, | Differential Revisions: #9661 | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:7 simonpj]: > Wait! > > I believe that you are saying that [...] Yes that's right. Tickets #8326 and #8327 cover everything I had to say about the code generated here. > Where would be a good place to document it? Perhaps with the primops for `(==)#`, `(>=)#`, etc? Or with `isTrue#`? Ideally with the comparison primops, but they are numerous and scattered throughout the list of primops, which is organized principally by type (`Char#`, then the integral types, etc.). There is some mention of this phenomenon in the Note `[Optimizing isTrue#]`, though you have to read between the lines a bit. It would be best to fix this of course, but if that stalls then I'll add a comment near the top of `primops.txt.pp`. > Speaking of which do you know why it behaves so badly? There is a special case for `cgCase` on an enumeration type of a primop application: in this case we always raise heap checks out of the alternatives. I think this is the entire reason for the difference between the code generated for the two versions. I don't see why it makes sense to have different logic for how to place the heap checks in this case compared to the general case, and I'm not entirely sure it isn't a historical accident. Further comments on #8326. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 06:10:12 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 06:10:12 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.b7dad573bba8ac4f98e1de5c32f7fd29@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: 8317 Related Tickets: #1498 | Differential Revisions: Phab:D343 -------------------------------------+------------------------------------- Comment (by rwbarton): I'm not convinced that we shouldn't just always do the heap check outside the case, even when there is only one branch that allocates. In the worst case we do an extra memory read (HpLim, probably in L1 cache), a comparison and a branch (which is highly predictable). However * In simple functions (like the one in #10676) we don't need to allocate stack if we do the heap check up front. However a heap check in an alternative in this case requires allocating a stack frame (not sure whether occurs in all cases, or whether it is avoidable), so then we do have to do a stack check up front instead which is almost as expensive. (The difference is that SpLim is in a register while HpLim must be stored in memory.) In addition the code becomes substantially larger because we have two separate entries to the GC. * In functions which need to allocate stack anyways, putting the heap check outside the case does mean we have to an extra check when we take a branch that does not allocate. On the other hand, we can then use the same GC entry code for the stack check and the heap check, so the code is again much smaller. This may pay for the extra instructions of the heap check, especially if the non-allocating branch(es) are infrequent anyways. At any rate it's simpler than the knot-tying discussed in this ticket, so I will try it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 07:30:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 07:30:34 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.498c4c43a2324b07c06d18418049b22f@haskell.org> #10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10059 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Yes I think we should probably treat `(~)` as "built-in syntax", like `(->)` and `[]`. You can't override, import, or hide these things. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 08:28:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 08:28:13 -0000 Subject: [GHC] #10678: integer-gmp's runS seems unnecessarily expensive In-Reply-To: <047.1e3027d49179affc6473e88cc8dec51a@haskell.org> References: <047.1e3027d49179affc6473e88cc8dec51a@haskell.org> Message-ID: <062.1b676058b8ffe2f8bf56657f86c743f1@haskell.org> #10678: integer-gmp's runS seems unnecessarily expensive -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Good! Can you give a small example of your last para? I bet it's something like {{{ case (runRW (\s -> I# x)) of (# _ , I# y) -> blah }}} I bet that you can make something similar happen with `catch#`. A new ticket, perhaps. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 08:34:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 08:34:24 -0000 Subject: [GHC] #10528: compile time performance regression with OverloadedStrings and Text In-Reply-To: <048.98ab82d16d4bd14b388cfa4fc2b927d4@haskell.org> References: <048.98ab82d16d4bd14b388cfa4fc2b927d4@haskell.org> Message-ID: <063.16f443130fd3c997624437c02d7ce7c9@haskell.org> #10528: compile time performance regression with OverloadedStrings and Text -------------------------------------+------------------------------------- Reporter: jakewheat | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Replying to [comment:34 afarmer]: > I realize I could be careful about assigning phases to the inline pragma on `baz` and both rules, but that seems extremely fiddly compared to just not inlining/rewriting the RHS to begin with. It may be fiddly but you absolutely must do it. In the rewrite sequence you give, the inlining for `baz` is active, so GHC could perfectly well rewrite {{{ bar (baz (quux z)) ---> bar () }}} What makes you think that rule "baz-quux" will get there first? Even if it usually does, some trivial thing might mean the rule missed on the first go, and then you'd inline `baz`. We initially tried to guarantee that if rules and inlinings were both active, the rules would "win" but it was flaky and unreliable. Hence phase control. If you want robust, predictable behaviour, you should use phases. Sorry! (And then there's no reason not to inline/apply rules in the RHS.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 08:35:14 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 08:35:14 -0000 Subject: [GHC] #10528: compile time performance regression with OverloadedStrings and Text In-Reply-To: <048.98ab82d16d4bd14b388cfa4fc2b927d4@haskell.org> References: <048.98ab82d16d4bd14b388cfa4fc2b927d4@haskell.org> Message-ID: <063.4306814e9ba70a99444c7dfa4f1b289b@haskell.org> #10528: compile time performance regression with OverloadedStrings and Text -------------------------------------+------------------------------------- Reporter: jakewheat | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Status is 'merge' because we should merge the patch as described in comment:34 into 7.10.3, if/when we release it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 08:39:54 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 08:39:54 -0000 Subject: =?utf-8?b?W0dIQ10gIzEwNzM0OiBwcHJpbnQgb2Yg4oCYbGV04oCZIGluc2lk?= =?utf-8?b?ZSDigJhkb+KAmSBwcmludHMgaW52YWxpZCBIYXNrZWxs?= Message-ID: <047.198f0614ed38423766e17028c03c3aa7@haskell.org> #10734: pprint of ?let? inside ?do? prints invalid Haskell -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.10.2 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- On GHC 7.10.1 {{{#!hs Prelude Language.Haskell.TH Language.Haskell.TH.Ppr> pprint <$> runQ [| do { let { x = 5 }; return x; } |] "do {let x_0 = 5; GHC.Base.return x_0}" }}} The let binding inside the resulting {{{do}}} should be inside curly braces too -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 08:45:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 08:45:38 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.ef71182932f52bcad0ac1fd930c53d64@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: 8317 Related Tickets: #1498 | Differential Revisions: Phab:D343 -------------------------------------+------------------------------------- Comment (by simonpj): Good point. Trying that is an excellent idea. Note that in a tree of (primop) conditionals, if even one branch allocates, then we'll do a heap check in all cases. It might be interesting to gather the following statistic in ticky-ticky profiling * Total number of heap checks * Total number of times that `Hp` is wound back to zero. This winding back is done by `adjustHpBackwards`. You can tell if you are winding back to zero because `vHp` is zero. If we wind back to zero, that means that we allocated nothing, so the original heap check was wasted. Then we can see what proportion of heap checks are wasted. I guess the worry is that this might happen a lot in some hot inner loop, but let's see. Thanks for doing this. If it looks reasonable it'd be a much simpler cleaner solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 08:47:00 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 08:47:00 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMDczNDogcHByaW50IG9mIOKAmGxldOKAmSBp?= =?utf-8?q?nside_=E2=80=98do=E2=80=99_prints_invalid_Haskell?= In-Reply-To: <047.198f0614ed38423766e17028c03c3aa7@haskell.org> References: <047.198f0614ed38423766e17028c03c3aa7@haskell.org> Message-ID: <062.6bfc4ab73c61ab0ad357c7c5ac9bad39@haskell.org> #10734: pprint of ?let? inside ?do? prints invalid Haskell -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Fuuzetsu): Also a problem on 7.10.2 The `Ppr` instance for `LetS` constructor is just not good enough. {{{#!hs Prelude Language.Haskell.TH.Ppr Language.Haskell.TH> pprint <$> runQ [| do { let { x = 5; y = 3 }; return x; } |] "do {let x_0 = 5\n y_1 = 3;\n GHC.Base.return x_0}" }}} Worst thing is that there is no easy way to override this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 08:51:45 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 08:51:45 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMDczNDogcHByaW50IG9mIOKAmGxldOKAmSBp?= =?utf-8?q?nside_=E2=80=98do=E2=80=99_prints_invalid_Haskell?= In-Reply-To: <047.198f0614ed38423766e17028c03c3aa7@haskell.org> References: <047.198f0614ed38423766e17028c03c3aa7@haskell.org> Message-ID: <062.999f7e3f61dda0428cbfd9207d4ee99c@haskell.org> #10734: pprint of ?let? inside ?do? prints invalid Haskell -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Fuuzetsu): One last comment in case someone else hits it. You can workaround with {{{#!hs Prelude Language.Haskell.TH Language.Haskell.TH.Ppr> pprint <$> runQ [| do { x <- return 5; return x; } |] "do {x_0 <- GHC.Base.return 5; GHC.Base.return x_0}" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 08:55:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 08:55:06 -0000 Subject: [GHC] #10732: Legal Bang Patterns cannot parse In-Reply-To: <042.4ad4dd039de0d1dea0d83f39e9f13584@haskell.org> References: <042.4ad4dd039de0d1dea0d83f39e9f13584@haskell.org> Message-ID: <057.1e84d296a1a40684a3c351c7d7ce5a20@haskell.org> #10732: Legal Bang Patterns cannot parse -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Parser) | Keywords: Bang Resolution: | Pattern Parser Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Parsing is always fiddly! I'd welcome someone looking into this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 08:59:52 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 08:59:52 -0000 Subject: [GHC] #10528: compile time performance regression with OverloadedStrings and Text In-Reply-To: <048.98ab82d16d4bd14b388cfa4fc2b927d4@haskell.org> References: <048.98ab82d16d4bd14b388cfa4fc2b927d4@haskell.org> Message-ID: <063.386f07521a2f6d7da24cf587b885f131@haskell.org> #10528: compile time performance regression with OverloadedStrings and Text -------------------------------------+------------------------------------- Reporter: jakewheat | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by afarmer): Ah, so much for my attempt to make my request seem like a non-HERMIT issue. :-P We would still like to have access to the original version of the rule (without inlining/rule application being performed on either side) for HERMIT's purposes. Is that possible? The rewriting of the RHS seems to happen even if HERMIT is the very first phase of the core2core pipeline, so I take it that it happens during desugaring? Might it be possible to delay until the first simplifier pass runs? To be concrete, I was proposing the following patch: {{{ diff --git a/compiler/simplCore/Simplify.hs b/compiler/simplCore/Simplify.hs index d816d3f..f9e3f92 100644 --- a/compiler/simplCore/Simplify.hs +++ b/compiler/simplCore/Simplify.hs @@ -2969,10 +2969,9 @@ simplRules env mb_new_nm rules , ru_fn = fn_name, ru_rhs = rhs , ru_act = act }) = do { (env, bndrs') <- simplBinders env bndrs - ; let lhs_env = updMode updModeForRuleLHS env - rhs_env = updMode (updModeForStableUnfoldings act) env - ; args' <- mapM (simplExpr lhs_env) args - ; rhs' <- simplExpr rhs_env rhs + ; let env' = updMode updModeForRuleLHS env + ; args' <- mapM (simplExpr env') args + ; rhs' <- simplExpr env' rhs ; return (rule { ru_bndrs = bndrs' , ru_fn = mb_new_nm `orElse` fn_name , ru_args = args' }}} which gets our testsuite passing again. I realize HERMIT support is probably not on GHC's critical path ;-) ... I'm just trying to find a work around so we can support GHC 7.10. Thanks for your help! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 09:07:51 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 09:07:51 -0000 Subject: [GHC] #10549: floatExpr tick break<2> In-Reply-To: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> References: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> Message-ID: <066.2d5ad0a6feefa9d0326fe317ef00b34a@haskell.org> #10549: floatExpr tick break<2> -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 09:18:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 09:18:49 -0000 Subject: [GHC] #10528: compile time performance regression with OverloadedStrings and Text In-Reply-To: <048.98ab82d16d4bd14b388cfa4fc2b927d4@haskell.org> References: <048.98ab82d16d4bd14b388cfa4fc2b927d4@haskell.org> Message-ID: <063.8ae146bb7761487067e41385e59e339f@haskell.org> #10528: compile time performance regression with OverloadedStrings and Text -------------------------------------+------------------------------------- Reporter: jakewheat | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by afarmer): As an example of what is happening, we are seeing rules like this: {{{ repH :: [a] -> [a] -> [a] {-# RULES "repH ++" [~] forall xs ys. repH (xs ++ ys) = repH xs . repH ys #-} }}} get to HERMIT as: {{{ "repH ++" forall xs ys. repH (xs ++ ys) = let f = repH xs g = repH ys in \ z -> f (g z) }}} In this case it is just an unfolding of composition, but some rules get rather gross on the RHS. The extra junk makes equational reasoning with these rules very fiddly and sort of breaks the correspondence with the source-level code. Some possible solutions that occur to me: 1. If we could get access to the rules before this inlining/rule application in the RHS occurs, then we wouldn't care what happens to them later. So just delaying things a bit. 2. If we don't inline/apply rules in the RHS at all (as above). 3. If we don't inline/apply rules in the RHS of rules marked with the NeverActive notation (rules intended for HERMIT use are generally NeverActive). 4. We implement our own concrete syntax for HERMIT rules and stop abusing RULES pragmas. I realize this is probably the "best" solution, but it's also an API-breaker that I'm guessing would land in 7.12 at the earliest. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 09:31:21 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 09:31:21 -0000 Subject: [GHC] #7206: Implement cheap build In-Reply-To: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> References: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> Message-ID: <061.596be925a7249bc38f7cc0cb6d0416c1@haskell.org> #7206: Implement cheap build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): I brought up this issue again in yesterday's GHC meeting. Simon's opinion was that while this doesn't produce a compelling performance improve with existing producers, it is a tool that may be nice to have available for use in user code. I've ported these patches to `master` in my `cheap-build` [https://github.com/ghc/ghc/compare/master...bgamari:cheap-build?expand=1 branch]. Sadly but not surprisingly the story told by `nofib` is still rather disappointing (showing only major changes), {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- cacheprof 0.0% +0.1% 0.173 0.173 -2.6% circsim 0.0% 0.0% +3.5% +3.6% 0.0% constraints 0.0% 0.0% +1.2% +1.2% 0.0% cryptarithm1 0.0% 0.0% -0.6% -0.4% 0.0% k-nucleotide 0.0% 0.0% -1.1% -1.1% 0.0% maillist 0.0% 0.0% 0.018 0.018 +5.6% wheel-sieve1 0.0% 0.0% +0.7% +0.9% 0.0% -------------------------------------------------------------------------------- Min 0.0% 0.0% -1.1% -1.1% -2.6% Max 0.0% +0.1% +3.5% +3.6% +5.6% Geometric Mean -0.0% +0.0% +0.2% +0.3% +0.0% }}} I'll be looking in to this later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 09:34:08 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 09:34:08 -0000 Subject: [GHC] #7206: Implement cheap build In-Reply-To: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> References: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> Message-ID: <061.fb04826659b9b13c20eb5b72a5e29d78@haskell.org> #7206: Implement cheap build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 09:42:21 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 09:42:21 -0000 Subject: [GHC] #9848: List.all does not fuse In-Reply-To: <049.2f5a48f3cdf200c755c1a1e10fe7787f@haskell.org> References: <049.2f5a48f3cdf200c755c1a1e10fe7787f@haskell.org> Message-ID: <064.9a103ad299c81b7e703c2a8e6736ebfa@haskell.org> #9848: List.all does not fuse -------------------------------------+------------------------------------- Reporter: klapaucius | Owner: ekmett Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by akio): * status: new => patch Comment: Thank you, I created Phab:D1126. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 10:01:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 10:01:40 -0000 Subject: [GHC] #10528: compile time performance regression with OverloadedStrings and Text In-Reply-To: <048.98ab82d16d4bd14b388cfa4fc2b927d4@haskell.org> References: <048.98ab82d16d4bd14b388cfa4fc2b927d4@haskell.org> Message-ID: <063.122d85d74b45e0ffc6061f2e4274d3d4@haskell.org> #10528: compile time performance regression with OverloadedStrings and Text -------------------------------------+------------------------------------- Reporter: jakewheat | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by afarmer): Proposed patch that implements Option 3 in my list above... which I think is the best short term solution. {{{ diff --git a/compiler/simplCore/Simplify.hs b/compiler/simplCore/Simplify.hs index d816d3f..0e4ca50 100644 --- a/compiler/simplCore/Simplify.hs +++ b/compiler/simplCore/Simplify.hs @@ -38,7 +38,7 @@ import CoreArity --import PrimOp ( tagToEnumKey ) -- temporalily commented out. See #8326 import Rules ( mkSpecInfo, lookupRule, getRules ) import TysPrim ( voidPrimTy ) --, intPrimTy ) -- temporalily commented out. See #8326 -import BasicTypes ( TopLevelFlag(..), isTopLevel, RecFlag(..) ) +import BasicTypes ( TopLevelFlag(..), isTopLevel, RecFlag(..), Activation(..) ) import MonadUtils ( foldlM, mapAccumLM, liftIO ) import Maybes ( orElse ) --import Unique ( hasKey ) -- temporalily commented out. See #8326 @@ -2970,7 +2970,9 @@ simplRules env mb_new_nm rules , ru_act = act }) = do { (env, bndrs') <- simplBinders env bndrs ; let lhs_env = updMode updModeForRuleLHS env - rhs_env = updMode (updModeForStableUnfoldings act) env + rhs_env = case act of + NeverActive -> lhs_env + _ -> updMode (updModeForStableUnfoldings act) env ; args' <- mapM (simplExpr lhs_env) args ; rhs' <- simplExpr rhs_env rhs ; return (rule { ru_bndrs = bndrs' }}} Since NeverActive rules are not actually applied by GHC, not rewriting their RHSs shouldn't change anything for real libraries, while still offering HERMIT access to the original rule without the extra inlining/rule application. This patch also allows our test suite to pass. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 10:08:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 10:08:13 -0000 Subject: [GHC] #10528: compile time performance regression with OverloadedStrings and Text In-Reply-To: <048.98ab82d16d4bd14b388cfa4fc2b927d4@haskell.org> References: <048.98ab82d16d4bd14b388cfa4fc2b927d4@haskell.org> Message-ID: <063.4f961e3c1584c1ded8f1bb7e49c13d04@haskell.org> #10528: compile time performance regression with OverloadedStrings and Text -------------------------------------+------------------------------------- Reporter: jakewheat | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Can you make a new ticket, about this issue (it's nothing to do with #10528), and explain there why you want the change. I see no compelling reason why we can't switch off rules and inlinings in the RHS just as we do in the LHS. We'd just need to carefully document the reason for doing so, and having a ticket to refer to is good. I don't really want to mess with 7.10 on this.... I don't think there would be knock on effects, but I would bet my life on it -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 10:10:04 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 10:10:04 -0000 Subject: [GHC] #7206: Implement cheap build In-Reply-To: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> References: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> Message-ID: <061.80c809d9f70bdc921d5586ab1bab7f0a@haskell.org> #7206: Implement cheap build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Is this with or without using `cheapBuild` for enumerations? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 10:13:59 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 10:13:59 -0000 Subject: [GHC] #10549: floatExpr tick break<2> In-Reply-To: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> References: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> Message-ID: <066.ab11b753c17c144ce5c6bccaf214e5d6@haskell.org> #10549: floatExpr tick break<2> -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Austin's previous fix, 46edc43cbe011978d903dd0b5f0ffc62c602fbaa, is the first bad commit here. It seems the commit forgot to treat the case of `-O` coming from `OPTIONS_GHC`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 10:20:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 10:20:33 -0000 Subject: [GHC] #10731: System.IO.openTempFile is not thread safe on Windows In-Reply-To: <051.f6b2ae5c769c1cac9a336c0052f78eb7@haskell.org> References: <051.f6b2ae5c769c1cac9a336c0052f78eb7@haskell.org> Message-ID: <066.ebc988fa940d819816170737640c06fd@haskell.org> #10731: System.IO.openTempFile is not thread safe on Windows -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by NeilMitchell): I've avoided this issue in the extra package (https://github.com/ndmitchell/extra/blob/master/src/System/IO/Extra.hs) with three techniques: * To avoid races within a process, I have a single IORef which I increment to find unique names. That guarantees that a process will never clash with itself. * To help avoid cross-process races I start that IORef at a random starting point (using the start time plus Process Id would be ideal, but I couldn't get that easily, so I use the time). * If all else fails, I retry up to 5 times on IO errors. With those features, I've yet to get a failure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 10:21:16 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 10:21:16 -0000 Subject: [GHC] #10549: floatExpr tick break<2> In-Reply-To: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> References: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> Message-ID: <066.14c65de40f82ac46dbdc483d2f850fbe@haskell.org> #10549: floatExpr tick break<2> -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): See also the questions I raised about that patch in https://phabricator.haskell.org/D727. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 10:52:09 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 10:52:09 -0000 Subject: [GHC] #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` Message-ID: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #1062, #1176, Differential Revisions: | #7666 -------------------------------------+------------------------------------- GHC has an internal copy of `pretty` in `compiler/utils/Pretty.hs`. Todo: * refactor GHC's copy to make it as similar as possible to `pretty`, without making any real code changes. * apply the bug fixes that `pretty` received to GHC's copy, making sure not to pick up any possible new bugs in the process. According to (1): "There is one situation where the laws for pretty are ambiguous and leave room for choice. GHC decided one way and pretty the other." * Find which law that is, and document the differences. This hopefully allows us to close the following tickets for free: #1062, #1176 and #7666, maybe more. Ideally we could remove GHC's copy altogether, but we're not there yet. GHC's copy uses FastString, which is supposedly needed for performance, whereas pretty uses `String`. (1) https://github.com/haskell/pretty/issues/1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 10:53:16 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 10:53:16 -0000 Subject: [GHC] #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` In-Reply-To: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> References: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> Message-ID: <060.3820705bf4e525d8052e29b8490f7dca@haskell.org> #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1062, #1176, | Differential Revisions: #7666 | -------------------------------------+------------------------------------- Changes (by thomie): * owner: => thomie Comment: I have patches. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 11:06:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 11:06:38 -0000 Subject: [GHC] #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` In-Reply-To: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> References: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> Message-ID: <060.2910daa08887b4788ee3c0076f7c0813@haskell.org> #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1062, #1176, | Differential Revisions: #7666 | -------------------------------------+------------------------------------- Comment (by bgamari): Replying to [comment:1 thomie]: > I have patches. Lovely. Will we be seeing them on Phab soon? On a related note, I've recently been thinking about error reporting with an eye for making the messages produced by GHC more useful to external tools. I've described one possible approach in ticket:8809#comment:3 which would involve making `Doc` a sort of free functor, allowing the insertion of rich AST objects into the document. Monadic semantics would certain patterns of projecting out these annotations into vanilla documents quite convenient. Unfortunately, the Hughes/Peyton-Jones pretty-printer isn't terribly well- suited for this as you need to know the width of a node's parent during construction. I've been meaning to explore adopting the Wadler/Leijen pretty-printer as Edward Kmett has already [http://hackage.haskell.org/package/wl-pprint-extras-3.5.0.5/docs/Text- PrettyPrint-Free.html demonstrated] that an implementation with annotations along the lines of my proposal is possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 11:29:03 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 11:29:03 -0000 Subject: [GHC] #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` In-Reply-To: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> References: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> Message-ID: <060.5356196fcd01a6575cc4c6fb5497e218@haskell.org> #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1062, #1176, | Differential Revisions: #7666, #8809 | -------------------------------------+------------------------------------- Changes (by thomie): * related: #1062, #1176, #7666 => #1062, #1176, #7666, #8809 Comment: Ok, maybe you want to comment on https://github.com/haskell/pretty/issues/1#issuecomment-78297997, where Trevor Elliott said: "I was hoping to extend the GHC pretty printer with the annotations, to get functionality like in the idris repl. Maybe extending their forked version with the annotations is the right path forward for that work :)" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 11:37:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 11:37:30 -0000 Subject: [GHC] #10678: integer-gmp's runS seems unnecessarily expensive In-Reply-To: <047.1e3027d49179affc6473e88cc8dec51a@haskell.org> References: <047.1e3027d49179affc6473e88cc8dec51a@haskell.org> Message-ID: <062.e50149a874cfe748614bcd5f4c7f12b0@haskell.org> #10678: integer-gmp's runS seems unnecessarily expensive -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * cc: bgamari (added) Comment: Interesting, there's some (albeit not perfect) overlap between the improved nofib cases with the regressed nofib cases noted in CompilerPerformance#Comparinginteger-gmp0.5and1.0 E.g. {{{ bernouilli -0.3% -8.2% -2.4% -2.4% 0.0% fasta -0.3% -5.1% -0.1% -0.1% 0.0% kahan -0.2% -11.4% +0.3% +0.3% 0.0% primetest -0.3% -18.5% -3.5% -3.6% 0.0% rsa -0.3% -19.8% 0.060 0.060 0.0% scs -0.4% -3.2% -2.0% -2.0% +14.3% symalg -0.3% -2.1% 0.024 0.024 0.0% wave4main -0.2% -4.1% -2.1% -2.1% -5.3% }}} vs ([https://gist.githubusercontent.com/bgamari/5de75ac998a346b70ce8/raw/ffc2bd4f7df2fe036e2b33869011b3b2b19e666f /nofib-integer-gmp-comparison.txt source]) {{{ Program Size Allocs Runtime Elapsed TotalMem bernouilli -68.7% +15.3% 0.092 0.092 0.0% fasta -76.4% -0.1% -0.6% -0.7% 0.0% kahan -74.0% +39.9% 0.131 0.131 0.0% primetest -67.5% +49.9% 0.050 0.050 0.0% rsa -67.9% +53.4% 0.012 0.012 0.0% scs -60.2% +6.8% +1.2% +1.2% 0.0% symalg -63.1% +9.5% 0.005 0.005 0.0% wave4main -69.5% +0.0% 0.109 0.109 0.0% }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 11:43:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 11:43:30 -0000 Subject: [GHC] #10639: Tight (non-allocating) loop freezes the scheduler In-Reply-To: <048.3130b8c9dae40d4cc95f52d78c185152@haskell.org> References: <048.3130b8c9dae40d4cc95f52d78c185152@haskell.org> Message-ID: <063.cc71d12365bc859092050147edaba7bc@haskell.org> #10639: Tight (non-allocating) loop freezes the scheduler -------------------------------------+------------------------------------- Reporter: gizmo.mk0 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): See Phab:D1127 for one possible wording. @gizmo.mk0, feel free to suggest improvements to the language. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 11:43:42 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 11:43:42 -0000 Subject: [GHC] #10639: Tight (non-allocating) loop freezes the scheduler In-Reply-To: <048.3130b8c9dae40d4cc95f52d78c185152@haskell.org> References: <048.3130b8c9dae40d4cc95f52d78c185152@haskell.org> Message-ID: <063.086267666e5293d2cd4b969b1babf7bc@haskell.org> #10639: Tight (non-allocating) loop freezes the scheduler -------------------------------------+------------------------------------- Reporter: gizmo.mk0 | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 11:44:01 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 11:44:01 -0000 Subject: [GHC] #10639: Tight (non-allocating) loop freezes the scheduler In-Reply-To: <048.3130b8c9dae40d4cc95f52d78c185152@haskell.org> References: <048.3130b8c9dae40d4cc95f52d78c185152@haskell.org> Message-ID: <063.ceba30f7958971e13ec8859f8b619d44@haskell.org> #10639: Tight (non-allocating) loop freezes the scheduler -------------------------------------+------------------------------------- Reporter: gizmo.mk0 | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1127 -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => Phab:D1127 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 12:07:19 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 12:07:19 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.df135bff426a0cb9351f6571825cff79@haskell.org> #10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10059 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Agreed that `~` should be built-in. Using `TypeOperators`, `GADTs` or `TypeFamilies` to enable `~` also makes sense, given the history. It sounds like you're moving toward the "non-magical in the parser but magical in the renamer" route, which I generally support. Thanks for pushing this along! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 12:29:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 12:29:05 -0000 Subject: [GHC] #7206: Implement cheap build In-Reply-To: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> References: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> Message-ID: <061.cbfc472e671e3da434dd9e25782dbb3b@haskell.org> #7206: Implement cheap build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): This is with `cheapBuild` being used for enumerations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 13:28:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 13:28:11 -0000 Subject: [GHC] #10549: floatExpr tick break<2> In-Reply-To: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> References: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> Message-ID: <066.37e6c42ccedb7f36285481000a35bb52@haskell.org> #10549: floatExpr tick break<2> -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T10549 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1128 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * testcase: => T10549 * differential: => Phab:D1128 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 14:05:59 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 14:05:59 -0000 Subject: [GHC] #3699: Wildcards in type functions In-Reply-To: <060.b01af1dc1c462193a392550aa45e1d6c@haskell.org> References: <060.b01af1dc1c462193a392550aa45e1d6c@haskell.org> Message-ID: <075.9ffa3aebcccd852878dbf1b291f82bda@haskell.org> #3699: Wildcards in type functions -------------------------------------+------------------------------------- Reporter: | Owner: msosn MartijnVanSteenbergen | Type: feature request | Status: closed Priority: low | Milestone: 7.12.1 Component: Compiler (Type | Version: 6.10.4 checker) | Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1092 -------------------------------------+------------------------------------- Comment (by MartijnVanSteenbergen): You are amazing! Thanks for building this. :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 14:27:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 14:27:43 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.62bd55ecb05dbf96d81ff804a3697f36@haskell.org> #10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10059 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by RyanGlScott): That leaves the remaining question of what fixity to give `(~)`. It seems pretty likely that no matter what is chosen, some code is going to break, so I suppose we should pick a fixity that is as consistent with existing uses of `(~)` as possible to minimize the fallout. Currently, it looks like `(~)` is neither `infixl` nor `infixr`, since the following code fails to parse: {{{#!hs f :: (Int ~ Char ~ Bool) => Int; f = 42 }}} I can't think of any scenarios where chaining `(~)` applications like this would be useful (chime in if you think otherwise!), so that behavior seems alright. What about the actual precedence? Intuitively, one would imagine `(~)` to have a very low precedence, as motivated by the original example in this ticket: {{{#!hs {-# LANGUAGE TypeFamilies #-} type family a \\ b infixl 9 \\ -- Currently parses like -- -- a \\ (b ~ Int) -- -- but probably ought to be -- -- (a \\ b) ~ Int f :: (a \\ b ~ Int) => a -> b -> b f = error "" }}} If we declared `infix 0 ~`, that would give the desired behavior. In a couple of corner cases, you'd still have to use parentheses. For example, in order to make `Int -> Int ~ Int -> Int` parse, you'd need to add parentheses like so: `(Int -> Int) ~ (Int -> Int)`. (Since that example wouldn't have parsed before anyway, this isn't that bad.) Therefore, it looks like the only existing code that would break from this idea would be ones that abuse `(~)` parsing magic, as in the aforementioned example. These could easily be fixed by adding parentheses where needed, so this is a very backwards-amenable change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 14:49:59 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 14:49:59 -0000 Subject: [GHC] #10713: Type family not reducing over data family In-Reply-To: <046.5ef44ab91bf829939e28ffc1eb7fff9f@haskell.org> References: <046.5ef44ab91bf829939e28ffc1eb7fff9f@haskell.org> Message-ID: <061.ac28d98bcf557e964838956bf1c8eec6@haskell.org> #10713: Type family not reducing over data family -------------------------------------+------------------------------------- Reporter: acowley | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.4 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"f063bd5413edf40f1b48e0f958410dcb6bf20b68/ghc" f063bd54/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f063bd5413edf40f1b48e0f958410dcb6bf20b68" Fix #10713. When doing the apartness/flattening thing, we really only need to eliminate non-generative tycons, not *all* families. (Data families are indeed generative!) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 15:04:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 15:04:33 -0000 Subject: [GHC] #10713: Type family not reducing over data family In-Reply-To: <046.5ef44ab91bf829939e28ffc1eb7fff9f@haskell.org> References: <046.5ef44ab91bf829939e28ffc1eb7fff9f@haskell.org> Message-ID: <061.1f21cd082d07151b280f916ec1839677@haskell.org> #10713: Type family not reducing over data family -------------------------------------+------------------------------------- Reporter: acowley | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler (Type | Version: 7.8.4 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T10713 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * testcase: => indexed-types/should_compile/T10713 * milestone: => 7.10.3 Comment: All set now. This should be quite straightforward to merge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 15:10:03 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 15:10:03 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.13e46ba5f258bd8f3dbb963e984b3d85@haskell.org> #10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10059 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dfeuer): I would think we'd want it to have even lower precedence than `->` to support easy use in contexts. This would require parentheses for some constraint kind applications, but I conjecture that's less common in practice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 15:12:47 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 15:12:47 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.9767643bb893e36821a5cb70c6af98db@haskell.org> #10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10059 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Sounds good to me. Needs examples in the user manual to show what is and is not ok. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 15:13:37 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 15:13:37 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.be1aa4dee2ead08ea5d83d7c0790a94f@haskell.org> #10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10059 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:14 dfeuer]: > I would think we'd want it to have even lower precedence than `->` to support easy use in contexts. Is that even possible at the moment? I thought that `(->)` had the lowest possible precedence: {{{#!hs $ inplace/bin/ghc-stage2 --interactive GHCi, version 7.11.20150727: http://www.haskell.org/ghc/ :? for help ?> :i (->) data (->) a b -- Defined in ?GHC.Prim? infixr 0 `(->)` }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 15:14:48 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 15:14:48 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.76c68a2efcc7bb2c32465dc4b3887296@haskell.org> #10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10059 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:16 RyanGlScott]: > Replying to [comment:14 dfeuer]: > > I would think we'd want it to have even lower precedence than `->` to support easy use in contexts. > > Is that even possible at the moment? I thought that `(->)` had the lowest possible precedence: > > {{{#!hs > $ inplace/bin/ghc-stage2 --interactive > GHCi, version 7.11.20150727: http://www.haskell.org/ghc/ :? for help > ?> :i (->) > data (->) a b -- Defined in ?GHC.Prim? > infixr 0 `(->)` > }}} Ze who writes the parser makes the rules. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 15:18:58 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 15:18:58 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.f96831cdc1098cb577b1a2c12dd64680@haskell.org> #10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10059 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): I would expect `~` to have lower precedence than everything except `=>`. This isn't a totally solid conviction, I could imagine changing my mind if I saw a suitable example, but I can't think of what such an example would look like. By the way, why can't ghci tell me about `:i (=>)`? :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 15:30:26 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 15:30:26 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.111104bc3f77482401cbd5f55e26ee9b@haskell.org> #10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10059 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by RyanGlScott): How exactly would this work? In order to make `(~)` have lower precedence than `(->)`, it seems to me we'd have to do one of the following [1]: 1. Give `(~)` a negative precedence. 2. Declare `infix 0 ~` and give `(->)` a higher precedence. Option 1 sounds particularly scary, since we'd be changing the lower bound of precedences. Option 2 allows users to define their own type operators that have lower precedence than `(->)`, and may cause some existing code to break. [1] That is, assuming that we're still committed to the idea of non- magically parsing `(~)` like any other type operator. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 15:34:45 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 15:34:45 -0000 Subject: [GHC] #10678: integer-gmp's runS seems unnecessarily expensive In-Reply-To: <047.1e3027d49179affc6473e88cc8dec51a@haskell.org> References: <047.1e3027d49179affc6473e88cc8dec51a@haskell.org> Message-ID: <062.199dcb47a1071780a98c1bc8ec865eaa@haskell.org> #10678: integer-gmp's runS seems unnecessarily expensive -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:7 simonpj]: > Good! Can you give a small example of your last para? I bet it's something like > {{{ > case (runRW (\s -> I# x)) of (# _ , I# y) -> blah > }}} Right, so in integer-gmp, where I previously had {{{ runS :: S RealWorld a -> a -- type S s a = State# s -> (# State# s, a #) runS m = case runRW# m of (# _, a #) -> a }}} when `a = BigNat` (`data BigNat = BN# ByteArray#`), I can instead use {{{ runS_BigNat :: S RealWorld BigNat -> BigNat runS_BigNat m = case runRW# (\s -> case m s of (# s', BN# ba #) -> (# s', ba #)) of (# _, ba #) -> BN# ba }}} The idea is * `m` usually simplifies to something like {{{ \s0 -> case newByteArray# n s0 of (# s1, arr #) -> case someGmpFunction arr s1 of s2 -> case unsafeFreezeByteArray# arr s2 of (# s3, farr #) -> (# s3, BN# farr #) }}} so in the "inner case" in `runS_BigNat`, the constructor `BN#` will cancel * Now the caller of `runS_BigNat` (say, `plusBigNat`) has the CPR property because the `BN#` constructor is visible outside the `runRW#` * Its caller in turn (say, `plusInteger`) looks like {{{ plusInteger (Jp# x) (Jp# y) = Jp# (plusBigNat x y) }}} but `Jp#`'s argument is unboxed for size reasons {{{ data Integer = ... | Jp# {-# UNPACK #-} !BigNat | ... }}} so `Jp# (plusBigNat x y)` would have meant extracting the field from a `BN#` and repacking it into a `Jp#`. But by calling the unboxed worker we can avoid ever allocating an intermediate `BN#` constructor. Note that the transformation `runS -> runS_BigNat` is always valid for any `m`, even though it looks like a nested CPR situation. The reason is that the context of the `runRW#` is strict in the second argument anyways. To determine when the transformation is a good idea for a particular argument `m`, we can use regular CPR analysis on the function `\s -> case m s of (# _, r #) -> r`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 15:40:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 15:40:06 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.12290f99269fc2e4e833078636823bc2@haskell.org> #10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10059 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): I was guessing that your option 1 would in fact be easy, though I haven't looked at any of the code involved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 15:48:07 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 15:48:07 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.1506c91c11b97d40678cb3ec1850cde1@haskell.org> #10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10059 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by RyanGlScott): One potential hiccup is that the [https://www.haskell.org/onlinereport/decls.html#sect4.4.2 Haskell 98 Report] requires all operators to have an integer precedence from 0 to 9, so we'd have to deviate from that to achieve option 1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 16:01:57 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 16:01:57 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.e99b1ce2cc09506e2c92de573be2fb80@haskell.org> #10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10059 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:21 RyanGlScott]: > One potential hiccup is that the [https://www.haskell.org/onlinereport/decls.html#sect4.4.2 Haskell 98 Report] requires all operators to have an integer precedence from 0 to 9, so we'd have to deviate from that to achieve option 1. Operator precedence is just syntax. There is no way to write a function `f :: OPERATOR -> Int` to get the precedence, nor could there be. This just isn't an issue. Allowing users to set arbitrary rational precedence values, or use some sort of general precedence DAG, would require a syntactic extension, but this does not, as it does not allow any new fixity declarations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 16:27:08 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 16:27:08 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.3cfaf75dfb788f3e4ce22f20dbf5d276@haskell.org> #10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10059 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by RyanGlScott): OK, so the idea is to still require that user-defined fixity declarations have precedence 0?9, but grant exceptions for certain types (e.g., `(~)`). I think this would technically meet the Haskell 2010 Report, so that's good. As far as implementation details go, it looks like `(->)`'s fixity is currently hardwired in [http://git.haskell.org/ghc.git/blob/f063bd5413edf40f1b48e0f958410dcb6bf20b68:/compiler/basicTypes/BasicTypes.hs#l344 BasicTypes.hs], so we could stick in {{{tildeFixity = Fixity (-1) Infix}}} there. I'm not aware of any bounds-checking code that would be tripped up by having a precedence lower than {{{minPrecedence = 0}}}, so I don't think that would be too invasive of a change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 16:55:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 16:55:05 -0000 Subject: [GHC] #9233: Compiler performance regression In-Reply-To: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> References: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> Message-ID: <062.d0edd9e6e423e0cb5cfb900d32add01f@haskell.org> #9233: Compiler performance regression -------------------------------------+------------------------------------- Reporter: augustss | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D73 -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"b5f1c851c34d34cadf536de6494e0ca79b806b67/ghc" b5f1c85/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b5f1c851c34d34cadf536de6494e0ca79b806b67" Test #9233 in perf/compiler/T9233 Summary: Ideally, we could use Phab's numbers to set the perf test correctly. But even if that's not possible, then I need help writing my `all.T`. With the version you see here, I get the following ``` Traceback (most recent call last): File "/Users/rae/Documents/ghc-valid/testsuite/driver/testlib.py", line 801, in do_test result = func(*[name,way] + args) TypeError: multimod_compile() takes exactly 4 arguments (6 given) ``` I don't know how to fix this. Test Plan: validate Reviewers: austin, bgamari, thomie Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1129 GHC Trac Issues: #9233 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 16:58:31 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 16:58:31 -0000 Subject: [GHC] #9233: Compiler performance regression In-Reply-To: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> References: <047.d7f8305aab93f7b0c3acb76dde30b078@haskell.org> Message-ID: <062.6253eaedaf43586364d759d291a76bdc@haskell.org> #9233: Compiler performance regression -------------------------------------+------------------------------------- Reporter: augustss | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | perf/compiler/T9233 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D73 -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => perf/compiler/T9233 * resolution: => fixed Comment: Ack. Bad commit message. Everything is actually OK with this commit! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 17:36:14 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 17:36:14 -0000 Subject: [GHC] #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` In-Reply-To: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> References: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> Message-ID: <060.498df8fed429fcee3275632e7bc83442@haskell.org> #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1062, #1176, | Differential Revisions: Phab:D1130 #7666, #8809 | -------------------------------------+------------------------------------- Changes (by thomie): * differential: => Phab:D1130 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 18:43:02 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 18:43:02 -0000 Subject: [GHC] #10528: compile time performance regression with OverloadedStrings and Text In-Reply-To: <048.98ab82d16d4bd14b388cfa4fc2b927d4@haskell.org> References: <048.98ab82d16d4bd14b388cfa4fc2b927d4@haskell.org> Message-ID: <063.066cd278692c49df150c91e740583f8f@haskell.org> #10528: compile time performance regression with OverloadedStrings and Text -------------------------------------+------------------------------------- Reporter: jakewheat | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by Roboguy): * cc: Roboguy (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 19:42:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 19:42:11 -0000 Subject: [GHC] #7666: excessive space and time usage for rendering (somewhat) deeply nested Docs In-Reply-To: <049.8cd4dd835967347997a66fc02360e8c1@haskell.org> References: <049.8cd4dd835967347997a66fc02360e8c1@haskell.org> Message-ID: <064.615d1abc701414de0625a16f75790d4e@haskell.org> #7666: excessive space and time usage for rendering (somewhat) deeply nested Docs -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: dterei Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.6.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => invalid Comment: Closing as invalid, since the pretty bug tracker is here: https://github.com/haskell/pretty/issues. I did try to build your testcase. But besides haxml, it also requires a package called tpdb, which itself has so many dependencies I gave up. If you do reopen on the pretty bug tracker, pleas make the test smaller, include build instructions, and expected output. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 19:48:07 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 19:48:07 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.1f937805851e60275a7fc22acd454869@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: 8317 Related Tickets: #1498 | Differential Revisions: Phab:D343 -------------------------------------+------------------------------------- Comment (by bgamari): Simon, indeed tying the knot would at very least require that two labels be unconditionally allocated and carried rather deeply into `StgCmmHeap`. Another issue is `heapCheck`, which is itself monadic as it ends up calling `getHeapUsage`. My initial thought was that `maybeAltHeapCheck` could look something like, {{{#!hs maybeAltHeapCheck :: (GcPlan,ReturnKind) -> FCode a -> FCode a maybeAltHeapCheck gc_plan code = do label1 <- allocLabelC label2 <- allocLabelC getHeapUsage $ \hpHw -> do emit $ case gc_plan of (NoGcInAlts, _) -> emptyOL (GcInAlts regs, AssignedDirectly) -> ... (GcInAlts regs, ReturnedTo lref off) -> ... code }}} Unfortunately this becomes quite invasive as you must pass those labels and the `CgInfoDownwards` pretty deeply into `StgCmmHeap`. It may be that a refactoring will help here but it seems a bit messy. In summary, as far as I can see there are several paths through the case alternative heap-check code (the code path column below shows the number of `newLabelC`s appearing in each function in parentheses), ||= `gc_plan` =||= `ret_kind` =||= canned entrypt =||= labels needed =||= code path =|| || `NoGcInAlts` || * || * || 0 || just run the code || || `GcInAlts` || `AssignedDirectly` || no || 1 || `altOrNoEscapeHeapCheck` -> `genericGC` (1) || || `GcInAlts` || `AssignedDirectly` || yes || 2 || `altOrNoEscapeHeapCheck` (2) -> `cannedGCReturnsTo` -> `heapCheck` || || `GcInAlts` || `ReturnedTo` || no || 1 || `altHeapCheckReturnsTo` -> `genericGC` (1) -> `heapCheck` || || `GcInAlts` || `ReturnedTo` || yes || 0 || `altHeapCheckReturnsTo` -> `cannedGCReturnsTo` -> `heapCheck` || -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 20:02:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 20:02:49 -0000 Subject: [GHC] #7666: excessive space and time usage for rendering (somewhat) deeply nested Docs In-Reply-To: <049.8cd4dd835967347997a66fc02360e8c1@haskell.org> References: <049.8cd4dd835967347997a66fc02360e8c1@haskell.org> Message-ID: <064.c6dadf7bcd2f9c6cea91e796056f6811@haskell.org> #7666: excessive space and time usage for rendering (somewhat) deeply nested Docs -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: dterei Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.6.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): To be fair: `tpdb` probably had less dependencies when you submitted this bug. It also depends on `wl-pprint-text` now, perhaps because pretty is too slow/uses too much memory... Anyway, please open a bug on the pretty bug tracker, it will hopefully get more attention there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 22:30:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 22:30:05 -0000 Subject: [GHC] #10736: threadWaitRead/registerFd unusable Message-ID: <044.a96ce04f26395251bc71867625bc2939@haskell.org> #10736: threadWaitRead/registerFd unusable -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The following program: {{{ module Main where import System.Posix.IO import GHC.Event main = do Just mgr <- getSystemEventManager fd <- openFd "/tmp/bleh" ReadOnly Nothing defaultFileFlags { nonBlock = True } key <- registerFd mgr (\_ _ -> putStrLn "hello") fd evtRead MultiShot return () }}} fails with: {{{ *** Exception: modifyFdOnce: permission denied (Operation not permitted) }}} Since `threadWaitRead` and family are implemented in terms of `registerFd`, they also fail with the same error. Perhaps I am misunderstanding how to use this function, but in this case the conditions that must hold true regarding file descriptors should be documented somewhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 22:40:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 22:40:06 -0000 Subject: [GHC] #1290: ghc runs preprocessor too much In-Reply-To: <044.83cfd67f7a50c84991c554d518089ac4@haskell.org> References: <044.83cfd67f7a50c84991c554d518089ac4@haskell.org> Message-ID: <059.142bcaa63b85753bc0b61d79edfa4d21@haskell.org> #1290: ghc runs preprocessor too much -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Driver | Version: 6.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * milestone: ? => 7.12.1 Comment: What if this information was cached in the interface file? Essentially, interface files should contain enough information for us to construct a `ModSummary`, and they are as recent as the source file we can just use this directly. (And we're going to read the interface file anyway shortly thereafter do check for recompilation avoidance.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 4 22:56:45 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Aug 2015 22:56:45 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.c4d840c4b0dad3a9a5ef52ea00fe0ffc@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: 8317 Related Tickets: #1498 | Differential Revisions: Phab:D343 -------------------------------------+------------------------------------- Comment (by simonpj): Before delving into this, let's try the simpler approach you suggested! simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 00:34:03 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 00:34:03 -0000 Subject: [GHC] #10737: GHC panic durring MVar operation Message-ID: <049.580b198cd1c514601e30fc759ca3d8fa@haskell.org> #10737: GHC panic durring MVar operation -------------------------------------+------------------------------------- Reporter: dohaqatar7 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The following error message was displayed while loading a program into ghci by executing `:r` in a ghci session: {{{ ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-mingw32): thread blocked indefinitely in an MVar operation Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The only edit made to the source file before compiling was the removal of an unnecessary `do` on line 20 of the source file. The `do` was used even though the monodic computations were written in a single line style. I have not been able to reproduce the panic at all. The source file, unedited since the panic, now compiles without error. The ghci session leading up to the crash is below {{{ *Main> :t runState (filterM untouchable [1..3]) M.empty runState (filterM untouchable [1..3]) M.empty :: ([Int], M.Map Int Int) *Main> runState (filterM untouchable [1..3]) M.empty ([2],fromList [(1,1),(2,1),(3,1),(4,3)]) *Main> runState (filterM untouchable [1..10]) M.empty ([2,5],fromList [(1,1),(2,1),(3,1),(4,3),(5,1),(6,6),(7,1),(8,7),(9,4),(10,8),(11,1),(12,16),(13,1),(14,10),(15,9),(16,15),(17,1),(18,21),(19,1),(20,22),(21,11),(22,14),(23,1),(24,36),(25,6),(26,16),(27,13),(28,28),(29,1),(30,42),(31,1),(32,31),(33,15),(34,20),(35,13),(36,55),(37,1),(38,22),(39,17),(40,50),(41,1),(42,54),(43,1),(44,40),(45,33),(46,26),(47,1),(48,76),(49,8),(50,43),(51,21),(52,46),(53,1),(54,66),(55,17),(56,64),(57,23),(58,32),(59,1),(60,108),(61,1),(62,34),(63,41),(64,63),(65,19),(66,78),(67,1),(68,58),(69,27),(70,74),(71,1)(72,123),(73,1),(74,40),(75,49),(76,64),(77,19),(78,90),(79,1),(80,106),(81,40)]) *Main> runState (filterM untouchable [1..100]) M.empty ([2,5,52,88Interrupted. *Main> *Main> *Main> *Main> *Main> *Main> *Main> *Main> *Main> :r [1 of 1] Compiling Main ( C:\Users\admin\Programming\Haskell\codegolf\Untouchable.hs, interpreted ) Ok, modules loaded: Main. *Main> ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-mingw32): thread blocked indefinitely in an MVar operation 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 Wed Aug 5 00:39:30 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 00:39:30 -0000 Subject: [GHC] #10737: GHC panic durring MVar operation In-Reply-To: <049.580b198cd1c514601e30fc759ca3d8fa@haskell.org> References: <049.580b198cd1c514601e30fc759ca3d8fa@haskell.org> Message-ID: <064.c4801dae726ce2665e1cc0e3647b3b1e@haskell.org> #10737: GHC panic durring MVar operation -------------------------------------+------------------------------------- Reporter: dohaqatar7 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by dohaqatar7): * Attachment "Untouchable.hs" added. Source file in question -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 02:50:34 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 02:50:34 -0000 Subject: [GHC] #10738: Make Exception datatypes into newtypes Message-ID: <050.5d465a0cdfbff2328b1c7589102aa667@haskell.org> #10738: Make Exception datatypes into newtypes -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 7.10.2 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #4961 Differential Revisions: | -------------------------------------+------------------------------------- Certain instances of `Exception` in `base` are datatypes with only one argument: {{{#!hs data RecUpdError = RecUpdError String data RecConError = RecConError String data RecSelError = RecSelError String data PatternMatchFail = PatternMatchFail String data NoMethodError = NoMethodError String data AssertionFailed = AssertionFailed String }}} Why not make these into `newtype`s? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 02:56:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 02:56:15 -0000 Subject: [GHC] #10738: Make Exception datatypes into newtypes In-Reply-To: <050.5d465a0cdfbff2328b1c7589102aa667@haskell.org> References: <050.5d465a0cdfbff2328b1c7589102aa667@haskell.org> Message-ID: <065.d8f6ffb32c01953fbc19d1ca0e42308a@haskell.org> #10738: Make Exception datatypes into newtypes -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: | RyanGlScott Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4961 | Differential Revisions: Phab:D1131 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * owner: => RyanGlScott * differential: => Phab:D1131 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 07:56:38 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 07:56:38 -0000 Subject: [GHC] #9218: Upgrade the version of MinGW shipped with GHC In-Reply-To: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> References: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> Message-ID: <062.06053cbc0d8c209c93ce36c361707b13@haskell.org> #9218: Upgrade the version of MinGW shipped with GHC -------------------------------------+------------------------------------- Reporter: komadori | Owner: gintas Type: task | Status: patch Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9014 | Blocking: 9215 Related Tickets: #3390 #10705 | Differential Revisions: Phab:D339 #10726 | -------------------------------------+------------------------------------- Comment (by thomie): awson: your patch is now in https://phabricator.haskell.org/D1123, maybe you could give it a quick glance and a thumbs up? Please either comment here or by creating an account on [wiki:Phabricator]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 08:00:59 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 08:00:59 -0000 Subject: [GHC] #9218: Upgrade the version of MinGW shipped with GHC In-Reply-To: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> References: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> Message-ID: <062.9e16bad8501e9ca36ecd0dbed3757cf0@haskell.org> #9218: Upgrade the version of MinGW shipped with GHC -------------------------------------+------------------------------------- Reporter: komadori | Owner: gintas Type: task | Status: patch Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9014 | Blocking: 9215 Related Tickets: #3390 #10705 | Differential Revisions: Phab:D339 #10726 | -------------------------------------+------------------------------------- Comment (by thomie): awson: do you have any idea what that test failure in `ghci/prog003` is about? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 08:10:47 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 08:10:47 -0000 Subject: [GHC] #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` In-Reply-To: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> References: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> Message-ID: <060.f04e34fbf770636c95a92851638fcda7@haskell.org> #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1062, #1176, | Differential Revisions: Phab:D1130 #7666, #8809 | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"9d24b060af190c89173f9d13260e6eb1ab7debc3/ghc" 9d24b060/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9d24b060af190c89173f9d13260e6eb1ab7debc3" Pretty: rename variables to the ones used by libraries/pretty (#10735) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 08:10:47 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 08:10:47 -0000 Subject: [GHC] #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` In-Reply-To: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> References: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> Message-ID: <060.b520beaa5b4efc5a6562709f6386f16c@haskell.org> #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1062, #1176, | Differential Revisions: Phab:D1130 #7666, #8809 | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"d7b053a25f17a02753780293bc1d417c5794e91f/ghc" d7b053a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d7b053a25f17a02753780293bc1d417c5794e91f" Pretty: reformat using style from libraries/pretty (#10735) This commit copies the code structure (what goes where), whitespace layout and comments from libraries/pretty/src/Text/PrettyPrint/HughesPJ.hs, with the intention to be able to later more easily compare the two files, and port bug fixes. I'm sorry this messes up git blame history, but there's no other way. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 08:10:47 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 08:10:47 -0000 Subject: [GHC] #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` In-Reply-To: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> References: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> Message-ID: <060.60bd356117bef1a3fc4e1382ade2ac7f@haskell.org> #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1062, #1176, | Differential Revisions: Phab:D1130 #7666, #8809 | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"25bc406209eaff04d1ba1f2ec65cbac098c27829/ghc" 25bc406/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="25bc406209eaff04d1ba1f2ec65cbac098c27829" Pretty: improve error messages (#10735) Again, following libraries/pretty. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 08:10:47 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 08:10:47 -0000 Subject: [GHC] #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` In-Reply-To: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> References: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> Message-ID: <060.1005f97e99345008b3142012ab04b3e5@haskell.org> #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1062, #1176, | Differential Revisions: Phab:D1130 #7666, #8809 | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"53484d3deff9fa9f8b3da01a4b375b4ea8a7ba05/ghc" 53484d3d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="53484d3deff9fa9f8b3da01a4b375b4ea8a7ba05" Pretty: remove superfluous parenthesis (#10735) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 08:10:47 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 08:10:47 -0000 Subject: [GHC] #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` In-Reply-To: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> References: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> Message-ID: <060.09f026c5be41a641ef46abbd69c48a02@haskell.org> #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1062, #1176, | Differential Revisions: Phab:D1130 #7666, #8809 | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"2d1eae26f83bdff3bc5f5eb98101e4fd718afd62/ghc" 2d1eae26/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2d1eae26f83bdff3bc5f5eb98101e4fd718afd62" Pretty: kill code that has been dead since 1997 (#10735) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 08:10:47 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 08:10:47 -0000 Subject: [GHC] #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` In-Reply-To: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> References: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> Message-ID: <060.480a2a8ccbad935f71a3448e7da90f83@haskell.org> #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1062, #1176, | Differential Revisions: Phab:D1130 #7666, #8809 | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"926e4288c5aabb75addcdc4cbdc106e74c11162d/ghc" 926e428/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="926e4288c5aabb75addcdc4cbdc106e74c11162d" Pretty: use BangPatterns instead of manual unboxing Ints (#10735) Follow same style as libraries/pretty, although some of it is pretty archaic, and could be improved with BangPatterns: * `get w _ | w == 0 && False = undefined` * `mkNest k _ | k `seq` False = undefined` }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 08:10:47 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 08:10:47 -0000 Subject: [GHC] #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` In-Reply-To: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> References: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> Message-ID: <060.0c6b16b1415a6b8e6ea99e1cbefd7902@haskell.org> #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1062, #1176, | Differential Revisions: Phab:D1130 #7666, #8809 | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"6f6d082124b24bd8437f95d99a8fd8844a0f6cd8/ghc" 6f6d082/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6f6d082124b24bd8437f95d99a8fd8844a0f6cd8" Pretty: Args of NilAbove/TextBeside/Nest/Union are always RDocs (#10735) Just following libraries/pretty. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 08:10:47 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 08:10:47 -0000 Subject: [GHC] #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` In-Reply-To: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> References: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> Message-ID: <060.9d4a2865b6d822cd24c6e4e78c6c188d@haskell.org> #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1062, #1176, | Differential Revisions: Phab:D1130 #7666, #8809 | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"f951ffc6e4aa8fad1f5dcb6fd013340bf792f92d/ghc" f951ffc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f951ffc6e4aa8fad1f5dcb6fd013340bf792f92d" Pretty: mimic pretty API more closely (#10735) Refactoring only. Nothing much to see here. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 08:10:47 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 08:10:47 -0000 Subject: [GHC] #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` In-Reply-To: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> References: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> Message-ID: <060.81ac81af4fec8d9e1bc1425645fc16ba@haskell.org> #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1062, #1176, | Differential Revisions: Phab:D1130 #7666, #8809 | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"85179b5821bb1010eede7cec43280c2cd7e59bd3/ghc" 85179b58/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="85179b5821bb1010eede7cec43280c2cd7e59bd3" Pretty: use replicate for spaces and multi_ch (#10735) Similar changes were made to pretty in commit 7575ab16430c876eaa1451b02465b6b103b3a519. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 08:21:51 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 08:21:51 -0000 Subject: [GHC] #10736: threadWaitRead/registerFd unusable In-Reply-To: <044.a96ce04f26395251bc71867625bc2939@haskell.org> References: <044.a96ce04f26395251bc71867625bc2939@haskell.org> Message-ID: <059.0919b47658acaa1cb531de37ba525b7a@haskell.org> #10736: threadWaitRead/registerFd unusable -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): What operating system is this on? The trouble is that the behavior of the functions backing the event manager are a bit platform-specific (in this way, it's a bit of a leaky abstraction, although I'm not sure we can do much better). Moreover, the platforms' documentation in this area tends to be quite poor, even in the case of Linux. In this particular case, you are running into the fact that `epoll` is [http://stackoverflow.com/questions/8057892/epoll-on-regular-files not] [http://stackoverflow.com/questions/8645721/why-does-select-select-work- with-disk-files-but-not-epoll?lq=1 supported] on regular files (the fact that this answer refers to the kernel's `eventpoll.c` for a definitive answer is an indication of just how lacking the documentation is in this area). I would like to improve the documentation for the event manager interfaces, but it require time to sort out where the relevant information can be found in the various platform documentation sources. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 08:50:22 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 08:50:22 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.3fc5e8803ccfebe274076f5199aa96e6@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: 8317 Related Tickets: #1498 | Differential Revisions: Phab:D343 -------------------------------------+------------------------------------- Comment (by bgamari): Actually, now that I look a bit more carefully `StgCmmMonad.codeOnly` may be exactly what is needed here. I'll need to think a bit more to make sure this breaks all of the potential cycles, but I am optimistic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 09:06:45 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 09:06:45 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.36bdbeb34d1d45c42ceae1750b25e52a@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: 8317 Related Tickets: #1498 | Differential Revisions: Phab:D343 -------------------------------------+------------------------------------- Comment (by bgamari): I think the issue here is that while on paper the code we emit is independent of our `GcPlan`, in practice we emit the code in most cases in `heapCheck` and **how** we end up in `heapCheck` is very much dependent on the `GcPlan`. I believe this almost does what we want, {{{#!hs maybeAltHeapCheck :: (GcPlan,ReturnKind) -> FCode a -> FCode a maybeAltHeapCheck gc_plan code = do codeOnly $ case gc_plan of (NoGcInAlts,_) -> code (GcInAlts regs, AssignedDirectly) -> altHeapCheck regs code (GcInAlts regs, ReturnedTo lret off) -> altHeapCheckReturnsTo regs regs lret off code }}} The trouble is you have now thrown away the heap usage information from the code you emitted in the `NoGcInAlts` case. Alternatively, you can lift the code emission out of `heapCheck`, but this breaks its nice interface, {{{#!hs maybeAltHeapCheck :: (GcPlan,ReturnKind) -> FCode a -> FCode a maybeAltHeapCheck gc_plan code = do codeOnly $ case gc_plan of (NoGcInAlts,_) -> return () -- These now only compute the heap usage of 'code' and do not emit it (GcInAlts regs, AssignedDirectly) -> altHeapCheck regs code (GcInAlts regs, ReturnedTo lret off) -> altHeapCheckReturnsTo regs regs lret off code code }}} Anyways, let's see how Reid's approach performs; perhaps this is all irrelevant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 09:10:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 09:10:23 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.8be53913fe1d90098bc117c62eb1897b@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: 8317 Related Tickets: #1498 | Differential Revisions: Phab:D343 -------------------------------------+------------------------------------- Comment (by simonpj): > Anyways, let's see how Reid's approach performs; perhaps this is all irrelevant Exactly! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 09:22:47 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 09:22:47 -0000 Subject: [GHC] #10720: New GHC fails to specialize imported function In-Reply-To: <045.bc4c23e626cc82190cc1366a8178cfbb@haskell.org> References: <045.bc4c23e626cc82190cc1366a8178cfbb@haskell.org> Message-ID: <060.53e57f828a372467b13de993156af45a@haskell.org> #10720: New GHC fails to specialize imported function -------------------------------------+------------------------------------- Reporter: wyager | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | performance, inline, specialize Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I tried this. It's all behaving as advertised * You need an `INLINEABLE` pragma on `(**)`. * If you add that, then `(**)` is getting specialised perfectly well; but it calls `(*)`, which is not. * So you need an `INLINEABLE` pragma on `(*)` too. Admittedly this isn't terribly clear. I'll add some new warnings to point out that this might be happening. Meanwhile, you might just want to confirm that this is indeed ok for you. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 09:24:56 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 09:24:56 -0000 Subject: [GHC] #10721: GHC INLINE pragma behavior does not match docs In-Reply-To: <045.27a53624f8de5b0505a3ea87e28c8301@haskell.org> References: <045.27a53624f8de5b0505a3ea87e28c8301@haskell.org> Message-ID: <060.55e15e0e076d4197fcdc9171bac21651@haskell.org> #10721: GHC INLINE pragma behavior does not match docs -------------------------------------+------------------------------------- Reporter: wyager | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | specialize, inline, inlinable, | pragma Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect | (amd64) warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Dead right. The warning is bogus. I'll fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 10:09:07 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 10:09:07 -0000 Subject: [GHC] #9430: implement more arithmetic operations natively in the LLVM backend In-Reply-To: <047.5faa8daf1edcacef61c9001ac8b43152@haskell.org> References: <047.5faa8daf1edcacef61c9001ac8b43152@haskell.org> Message-ID: <062.ca764d7d5e04f75a9252296a39be7937@haskell.org> #9430: implement more arithmetic operations natively in the LLVM backend -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: michalt Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | primops/should_run/T9430 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by michalt): * status: new => closed * resolution: => fixed Comment: Replying to [comment:15 rwbarton]: > But MO_U_Mul2 was done in 82ffc80d (comment:9) right? Yes, I think the 3 commits now cover all the ops in the ticket (first commit for the `llvm.*.with.overflow` ones, and then one for each of `MO_U_{Mul2,QuotRem2}`). So I hope it's ok to close it. :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 11:07:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 11:07:15 -0000 Subject: [GHC] #1062: Bad output from Text.PrettyPrint.HughesPJ In-Reply-To: <044.a7d5fe3f83742309611eefb0d3dc89dd@haskell.org> References: <044.a7d5fe3f83742309611eefb0d3dc89dd@haskell.org> Message-ID: <059.12e2b06bbbfb8caecd9395f0c24c9a07@haskell.org> #1062: Bad output from Text.PrettyPrint.HughesPJ -------------------------------------+------------------------------------- Reporter: igloo | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: ? Component: Core Libraries | Version: 6.6 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: pp1 Blocked By: | Blocking: Related Tickets: #669 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #669 Comment: Replying to [comment:3 thorkilnaur]: > This is actually a duplicate of #669. Reclosing. thorkilnaur and benedikt were the last ones to truly understand the pretty library, and I trust their judgement on this. Replying to [comment:6 igloo]: > Reopening, as this ticket is for the bad output of the pp1 test. The pp1 test is nowhere to be found, and the pretty bug tracker is at https://github.com/haskell/pretty/issues nowadays. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 12:43:21 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 12:43:21 -0000 Subject: [GHC] #10724: ghci crashing when using copy/paste in Gnome Terminal on Debian Jessie In-Reply-To: <048.3d43e86871e2f47f3491fb5fe466e924@haskell.org> References: <048.3d43e86871e2f47f3491fb5fe466e924@haskell.org> Message-ID: <063.e89a1ad3dcf71814a00edea88e37c0d2@haskell.org> #10724: ghci crashing when using copy/paste in Gnome Terminal on Debian Jessie -------------------------------+----------------------------------------- Reporter: martinvlk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #3656 | Differential Revisions: -------------------------------+----------------------------------------- Comment (by martinvlk): After further testing I found it is reated to pressing Ctrl+C in the ghci repl. However, I also fouond that I only get this behaviour when I start ghci via cabal (cabal repl). When I start ghci directly, it handles Ctrl+C gracefully, no errors. So I think this is probably more a cabal error than ghci? M. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 12:44:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 12:44:08 -0000 Subject: [GHC] #2747: Excessive Memory Usage: space leak with foldl' on Integer In-Reply-To: <044.00f0ddc6265bd8f5349ed085d7f86a62@haskell.org> References: <044.00f0ddc6265bd8f5349ed085d7f86a62@haskell.org> Message-ID: <059.f62555830464cf86e38531e185897645@haskell.org> #2747: Excessive Memory Usage: space leak with foldl' on Integer -------------------------------------+--------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Test Case: | -------------------------------------+--------------------------------- Comment (by Ben Gamari ): In [changeset:"dd7e1880ae078a2d9f254dc5d8f330121e0ec291/ghc" dd7e1880/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="dd7e1880ae078a2d9f254dc5d8f330121e0ec291" Add framework flags when linking a dynamic library This fixes the GHC side of trac #10568. So `cabal install --ghc-options="-framework GLUT" GLUT` creates a correctly linked GLUT.dylib. We still need to explictly pass `--ghc-options="-framework GLUT"` because the Cabal side #10568 is not fixed. Update: the Cabal side of #10568 is fixed by [Cabal#2747](https://github.com/haskell/cabal/pull/2747) Test Plan: validate Reviewers: austin, rwbarton, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D1115 GHC Trac Issues: #10568 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 12:44:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 12:44:08 -0000 Subject: [GHC] #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac In-Reply-To: <045.16a6419c70e069ea547a1b942e636370@haskell.org> References: <045.16a6419c70e069ea547a1b942e636370@haskell.org> Message-ID: <060.83b46ce951f4cb8fbdcdbfb81c01eea8@haskell.org> #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac -------------------------------+----------------------------------------- Reporter: George | Owner: darchon Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1115 -------------------------------+----------------------------------------- Comment (by Ben Gamari ): In [changeset:"dd7e1880ae078a2d9f254dc5d8f330121e0ec291/ghc" dd7e1880/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="dd7e1880ae078a2d9f254dc5d8f330121e0ec291" Add framework flags when linking a dynamic library This fixes the GHC side of trac #10568. So `cabal install --ghc-options="-framework GLUT" GLUT` creates a correctly linked GLUT.dylib. We still need to explictly pass `--ghc-options="-framework GLUT"` because the Cabal side #10568 is not fixed. Update: the Cabal side of #10568 is fixed by [Cabal#2747](https://github.com/haskell/cabal/pull/2747) Test Plan: validate Reviewers: austin, rwbarton, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D1115 GHC Trac Issues: #10568 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 12:44:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 12:44:08 -0000 Subject: [GHC] #10639: Tight (non-allocating) loop freezes the scheduler In-Reply-To: <048.3130b8c9dae40d4cc95f52d78c185152@haskell.org> References: <048.3130b8c9dae40d4cc95f52d78c185152@haskell.org> Message-ID: <063.ab5485e0ba33c2571199dcfbe67f79a6@haskell.org> #10639: Tight (non-allocating) loop freezes the scheduler -------------------------------------+------------------------------------- Reporter: gizmo.mk0 | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1127 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4c55f14d0ab0f2b099c475a9810012f645bb059e/ghc" 4c55f14d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4c55f14d0ab0f2b099c475a9810012f645bb059e" users_guide: Add note about #367 to Bugs section This is a long-standing bug and should be mentioned in the users guide, as noted in #10639. Test Plan: Carefully check language. Reviewers: simonpj, rwbarton, austin Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D1127 GHC Trac Issues: #10639, #367 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 12:44:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 12:44:08 -0000 Subject: [GHC] #367: Infinite loops can hang Concurrent Haskell In-Reply-To: <046.5a2b87104f229d7899f0f85ea5bfdf9e@haskell.org> References: <046.5a2b87104f229d7899f0f85ea5bfdf9e@haskell.org> Message-ID: <061.feebbdc0188a35d4ec69327cc694f2ab@haskell.org> #367: Infinite loops can hang Concurrent Haskell -------------------------------------+------------------------------------- Reporter: simonpj | Owner: ezyang Type: bug | Status: new Priority: lowest | Milestone: ? Component: Compiler | Version: 6.4.1 Resolution: None | Keywords: scheduler | allocation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | concurrent/should_run/T367, | concurrent/should_run/T367_letnoescape Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4c55f14d0ab0f2b099c475a9810012f645bb059e/ghc" 4c55f14d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4c55f14d0ab0f2b099c475a9810012f645bb059e" users_guide: Add note about #367 to Bugs section This is a long-standing bug and should be mentioned in the users guide, as noted in #10639. Test Plan: Carefully check language. Reviewers: simonpj, rwbarton, austin Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D1127 GHC Trac Issues: #10639, #367 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 12:44:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 12:44:08 -0000 Subject: [GHC] #10457: Revise/remove custom mapM implementation for lists In-Reply-To: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> References: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> Message-ID: <059.4067509199eb7ac883601e3e32a07e15@haskell.org> #10457: Revise/remove custom mapM implementation for lists -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.12.1 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1124 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"60297486fddd5c9695e2263c2ae46fa90f0feb9e/ghc" 60297486/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="60297486fddd5c9695e2263c2ae46fa90f0feb9e" Drop custom mapM impl for [] See https://mail.haskell.org/pipermail/libraries/2015-May/025708.html for motivation. This fixes #10457 Test Plan: Validate Reviewers: hvr, austin Subscribers: simonmar, thomie, dolio Differential Revision: https://phabricator.haskell.org/D1124 GHC Trac Issues: #10457 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 12:44:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 12:44:08 -0000 Subject: [GHC] #9848: List.all does not fuse In-Reply-To: <049.2f5a48f3cdf200c755c1a1e10fe7787f@haskell.org> References: <049.2f5a48f3cdf200c755c1a1e10fe7787f@haskell.org> Message-ID: <064.ffd210a74c7e3d8b8f38ec3325ac52dd@haskell.org> #9848: List.all does not fuse -------------------------------------+------------------------------------- Reporter: klapaucius | Owner: ekmett Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"22bbc1cf209d44b8bb8897ae7a35f9ebaf411b10/ghc" 22bbc1cf/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="22bbc1cf209d44b8bb8897ae7a35f9ebaf411b10" Make sure that `all`, `any`, `and`, and `or` fuse (#9848) Test Plan: validate Reviewers: hvr, austin, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D1126 GHC Trac Issues: #9848 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 12:44:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 12:44:08 -0000 Subject: [GHC] #10706: Make -fcpr-off a dynamic flag In-Reply-To: <046.93a9ca311aa12689c8b9087cc77d185d@haskell.org> References: <046.93a9ca311aa12689c8b9087cc77d185d@haskell.org> Message-ID: <061.cb1e9293bc2ee460d4aaef4f9af667c0@haskell.org> #10706: Make -fcpr-off a dynamic flag -------------------------------------+------------------------------------- Reporter: darchon | Owner: darchon Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1110 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"ecb1752ffa12dfa71053f640e6cce64d15e47e8f/ghc" ecb1752f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ecb1752ffa12dfa71053f640e6cce64d15e47e8f" Make -fcpr-off a dynamic flag Test Plan: validate Reviewers: austin, goldfire, simonpj, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D1110 GHC Trac Issues: #10706 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 12:44:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 12:44:08 -0000 Subject: [GHC] #10704: Can't lookup fixities of infix types in Template Haskell In-Reply-To: <050.da392650782a8199b770d3d93e898cab@haskell.org> References: <050.da392650782a8199b770d3d93e898cab@haskell.org> Message-ID: <065.c5a0a3f1e82d692346a8b8f9db6c26c9@haskell.org> #10704: Can't lookup fixities of infix types in Template Haskell -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: | RyanGlScott Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1109 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"575abf42e218925e456bf765abb14f069ac048a0/ghc" 575abf42/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="575abf42e218925e456bf765abb14f069ac048a0" Add Fixity info for infix types Template Haskell allows reification of fixity for infix functions and data constructors, and not for infix types. This adds a `Fixity` field to the relevant `Info` constructors that can have infix types (`ClassI`, `TyConI`, and `FamilyI`). I don't think that `VarI` or `PrimTyConI` can be infix, but I could be wrong. Test Plan: ./validate Reviewers: austin, goldfire, bgamari Reviewed By: goldfire, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1109 GHC Trac Issues: #10704 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 12:44:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 12:44:08 -0000 Subject: [GHC] #10738: Make Exception datatypes into newtypes In-Reply-To: <050.5d465a0cdfbff2328b1c7589102aa667@haskell.org> References: <050.5d465a0cdfbff2328b1c7589102aa667@haskell.org> Message-ID: <065.9f3e7c6e56218bfb90820f7f60a0cfed@haskell.org> #10738: Make Exception datatypes into newtypes -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: | RyanGlScott Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4961 | Differential Revisions: Phab:D1131 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b12dba7829742de98a483645142c7962b9dd9f3f/ghc" b12dba78/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b12dba7829742de98a483645142c7962b9dd9f3f" Make Exception datatypes into newtypes Certain instances of `Exception` are simply datatypes with only one argument, which should be `newtype`s. Reviewers: ekmett, hvr, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1131 GHC Trac Issues: #10738 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 12:47:29 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 12:47:29 -0000 Subject: [GHC] #10706: Make -fcpr-off a dynamic flag In-Reply-To: <046.93a9ca311aa12689c8b9087cc77d185d@haskell.org> References: <046.93a9ca311aa12689c8b9087cc77d185d@haskell.org> Message-ID: <061.e868ca608f2810987cb6f2cdaf3b16ec@haskell.org> #10706: Make -fcpr-off a dynamic flag -------------------------------------+------------------------------------- Reporter: darchon | Owner: darchon Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1110 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 12:49:18 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 12:49:18 -0000 Subject: [GHC] #10457: Revise/remove custom mapM implementation for lists In-Reply-To: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> References: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> Message-ID: <059.2da5f258fa4408054c6a6c3aebc44bee@haskell.org> #10457: Revise/remove custom mapM implementation for lists -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.12.1 Component: libraries/base | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1124 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 12:49:47 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 12:49:47 -0000 Subject: [GHC] #10738: Make Exception datatypes into newtypes In-Reply-To: <050.5d465a0cdfbff2328b1c7589102aa667@haskell.org> References: <050.5d465a0cdfbff2328b1c7589102aa667@haskell.org> Message-ID: <065.005fb0aa998c49772900a8912abf728e@haskell.org> #10738: Make Exception datatypes into newtypes -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: | RyanGlScott Type: feature request | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4961 | Differential Revisions: Phab:D1131 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 12:50:18 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 12:50:18 -0000 Subject: [GHC] #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac In-Reply-To: <045.16a6419c70e069ea547a1b942e636370@haskell.org> References: <045.16a6419c70e069ea547a1b942e636370@haskell.org> Message-ID: <060.2d73fe4f761479c2bc95793fe683bd3f@haskell.org> #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac -------------------------------+----------------------------------------- Reporter: George | Owner: darchon Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2-rc1 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1115 -------------------------------+----------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 12:51:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 12:51:24 -0000 Subject: [GHC] #10704: Can't lookup fixities of infix types in Template Haskell In-Reply-To: <050.da392650782a8199b770d3d93e898cab@haskell.org> References: <050.da392650782a8199b770d3d93e898cab@haskell.org> Message-ID: <065.65fe6dcb809a928b453f4f037f385c00@haskell.org> #10704: Can't lookup fixities of infix types in Template Haskell -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: | RyanGlScott Type: feature request | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1109 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 13:09:00 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 13:09:00 -0000 Subject: [GHC] #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac In-Reply-To: <045.16a6419c70e069ea547a1b942e636370@haskell.org> References: <045.16a6419c70e069ea547a1b942e636370@haskell.org> Message-ID: <060.680bc595d04eec6a023db9d14cbb65eb@haskell.org> #10568: Regression from 7.8.4, loading GLUT into GHCI fails on the Mac -------------------------------+----------------------------------------- Reporter: George | Owner: darchon Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2-rc1 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1115 -------------------------------+----------------------------------------- Changes (by bgamari): * status: closed => merge Comment: It might be good to have this in 7.10.3 if it comes to fruition. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 13:10:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 13:10:15 -0000 Subject: [GHC] #10739: Resuscitate the humble ticky-ticky profiler Message-ID: <046.7fb5f2d03b6936365a37558b137e1612@haskell.org> #10739: Resuscitate the humble ticky-ticky profiler -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The [https://ghc.haskell.org/trac/ghc/wiki/Debugging/TickyTicky ticky- ticky profiler] is known to be quite bit-rotted. Indeed there currently isn't even a definitive list of the counters, much less what they counter and whether they are still accurate. That being said, it can be quite useful and is worth putting effort into bringing back up to grade. There are a few things that need to be done here, 1. Collect a list of the existing counters 2. Work out what they are supposed to be measuring 3. Decide which still have a chance of being useful and accurate 4. ??? 5. Profile! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 13:11:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 13:11:27 -0000 Subject: [GHC] #10739: Resuscitate the humble ticky-ticky profiler In-Reply-To: <046.7fb5f2d03b6936365a37558b137e1612@haskell.org> References: <046.7fb5f2d03b6936365a37558b137e1612@haskell.org> Message-ID: <061.dce056b7d6d15f218e991eff0c309ed0@haskell.org> #10739: Resuscitate the humble ticky-ticky profiler -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Today I added a list of the existing counters to the [https://ghc.haskell.org/trac/ghc/wiki/Debugging/TickyTicky#Ticky- Tickycounters Ticky-Ticky page]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 13:11:50 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 13:11:50 -0000 Subject: [GHC] #10739: Resuscitate the humble ticky-ticky profiler In-Reply-To: <046.7fb5f2d03b6936365a37558b137e1612@haskell.org> References: <046.7fb5f2d03b6936365a37558b137e1612@haskell.org> Message-ID: <061.c1e653600911ff48b312751ecb6966c0@haskell.org> #10739: Resuscitate the humble ticky-ticky profiler -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > The [https://ghc.haskell.org/trac/ghc/wiki/Debugging/TickyTicky ticky- > ticky profiler] is known to be quite bit-rotted. Indeed there currently > isn't even a definitive list of the counters, much less what they counter > and whether they are still accurate. That being said, it can be quite > useful and is worth putting effort into bringing back up to grade. > > There are a few things that need to be done here, > > 1. Collect a list of the existing counters > 2. Work out what they are supposed to be measuring > 3. Decide which still have a chance of being useful and accurate > 4. ??? > 5. Profile! New description: The [https://ghc.haskell.org/trac/ghc/wiki/Debugging/TickyTicky ticky- ticky profiler] is known to be quite bit-rotted. Indeed there currently isn't even a definitive list of the counters, much less what they counter and whether they are still accurate. That being said, it can be quite useful and is worth putting effort into bringing back up to grade. There are a few things that need to be done here, 1. Collect a list of the existing counters 2. Work out what they are supposed to be measuring 3. Decide which still have a chance of being useful and accurate 4. Fix the counters as necessary 5. ??? 6. Profile! -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 13:12:21 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 13:12:21 -0000 Subject: [GHC] #10740: Ensure that ticky, profiler, and GC allocation numbers agree Message-ID: <046.facae83a9f3a186a7ce58910a20dae6f@haskell.org> #10740: Ensure that ticky, profiler, and GC allocation numbers agree -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Currently we have several subsystems independently tracking allocations. It is very likely there are discrepancies between them. Ensuring that they agree would be a great way to test each of them (especially ticky, which is almost certainly bitrotted, see #10739). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 13:25:02 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 13:25:02 -0000 Subject: [GHC] #10720: New GHC fails to specialize imported function In-Reply-To: <045.bc4c23e626cc82190cc1366a8178cfbb@haskell.org> References: <045.bc4c23e626cc82190cc1366a8178cfbb@haskell.org> Message-ID: <060.16d46ba8f21ada2bb97e10f0f11f05ee@haskell.org> #10720: New GHC fails to specialize imported function -------------------------------------+------------------------------------- Reporter: wyager | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | performance, inline, specialize Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"a4261549afaee56b00fbea1b4bc1a07c95e60929/ghc" a426154/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a4261549afaee56b00fbea1b4bc1a07c95e60929" Warn about missed specialisations for imports This change was provoked by Trac #10720, where a missing INLINEABLE pragma gave very poor performance. The change is to warn when an imported function is not specialised in a situation where the user expects it to be. New flags -fwarn-missed-specialisations -fwarn-all-missed-specialisations Documented in user manual. See Note [Warning about missed specialisations] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 13:25:02 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 13:25:02 -0000 Subject: [GHC] #10721: GHC INLINE pragma behavior does not match docs In-Reply-To: <045.27a53624f8de5b0505a3ea87e28c8301@haskell.org> References: <045.27a53624f8de5b0505a3ea87e28c8301@haskell.org> Message-ID: <060.61e00a381e41246fa3564ec5881ea31d@haskell.org> #10721: GHC INLINE pragma behavior does not match docs -------------------------------------+------------------------------------- Reporter: wyager | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | specialize, inline, inlinable, | pragma Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect | (amd64) warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"617f6966b5aaedd3ecd3f4c0f3735253187b7ff5/ghc" 617f6966/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="617f6966b5aaedd3ecd3f4c0f3735253187b7ff5" Do not complain about SPECIALISE for INLINE Fixes Trac #10721. See Note [SPECIALISE on INLINE functions] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 13:37:35 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 13:37:35 -0000 Subject: [GHC] #10724: ghci crashing when using copy/paste in Gnome Terminal on Debian Jessie In-Reply-To: <048.3d43e86871e2f47f3491fb5fe466e924@haskell.org> References: <048.3d43e86871e2f47f3491fb5fe466e924@haskell.org> Message-ID: <063.6343fe34be7fb451505ca52a822ee120@haskell.org> #10724: ghci crashing when using copy/paste in Gnome Terminal on Debian Jessie -------------------------------+----------------------------------------- Reporter: martinvlk | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.10.2 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #3656 | Differential Revisions: -------------------------------+----------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => duplicate Comment: Thanks, sounds like it is https://github.com/haskell/cabal/issues/1885 then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 15:50:02 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 15:50:02 -0000 Subject: [GHC] #10615: Panic; no skolem info (partial type signatures) In-Reply-To: <047.cefe16dab67fa27c50fe96bd91e89a00@haskell.org> References: <047.cefe16dab67fa27c50fe96bd91e89a00@haskell.org> Message-ID: <062.22ef8d45115942e0a7ab8610f443fed6@haskell.org> #10615: Panic; no skolem info (partial type signatures) -------------------------------------+------------------------------------- Reporter: holzensp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"953648127cea2836ec134b03a966695ac0b36434/ghc" 95364812/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="953648127cea2836ec134b03a966695ac0b36434" Tidy up and refactor wildcard handling When examining #10615, I found the wildcard handling hard to understand. This patch refactors quite a bit, but with no real change in behaviour. * Split out TcIdSigInfo from TcSigInfo, as a separate type, like TcPatSynInfo. * Make TcIdSigInfo express more invariants by pushing the wildard info into TcIdSigBndr * Remove all special treatment of unification variables that arise from wildcards; so the TauTv of TcType.MetaInfo loses its Bool argument. A ton of konck on changes. The result is significantly simpler, I think. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 15:50:03 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 15:50:03 -0000 Subject: [GHC] #10615: Panic; no skolem info (partial type signatures) In-Reply-To: <047.cefe16dab67fa27c50fe96bd91e89a00@haskell.org> References: <047.cefe16dab67fa27c50fe96bd91e89a00@haskell.org> Message-ID: <062.dddb7f5fbe8e718c7d415e75cc5b0b57@haskell.org> #10615: Panic; no skolem info (partial type signatures) -------------------------------------+------------------------------------- Reporter: holzensp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"28096b274a3803b8a479c5dd94ebda655a15566c/ghc" 28096b2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="28096b274a3803b8a479c5dd94ebda655a15566c" Fix quantification for inference with sigs When we are *inferring* the type of a let-bound function, we might still have a type signature. And we must be sure to quantify over its type variables, else you get the crash in Trac #10615. See Note [Which type variables to quantify] in TcSimplify }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 15:51:59 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 15:51:59 -0000 Subject: [GHC] #10266: Split base for Backpack In-Reply-To: <045.81e58b6e2b97dd039d014c76c016ea80@haskell.org> References: <045.81e58b6e2b97dd039d014c76c016ea80@haskell.org> Message-ID: <060.60dbfda66bd832fefe8de89f55bf5a1e@haskell.org> #10266: Split base for Backpack -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: low | Milestone: Component: libraries/base | Version: 7.11 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * cc: luite, nomeata (added) Comment: See also the wiki page on [wiki:SplitBase]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 15:52:22 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 15:52:22 -0000 Subject: [GHC] #10615: Panic; no skolem info (partial type signatures) In-Reply-To: <047.cefe16dab67fa27c50fe96bd91e89a00@haskell.org> References: <047.cefe16dab67fa27c50fe96bd91e89a00@haskell.org> Message-ID: <062.727642ea392e7e5ed20d074b345e0424@haskell.org> #10615: Panic; no skolem info (partial type signatures) -------------------------------------+------------------------------------- Reporter: holzensp | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: partial- | sigs/should_fail/T10615 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => partial-sigs/should_fail/T10615 * status: new => closed * resolution: => fixed Comment: Thanks for the great bug report. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 15:53:04 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 15:53:04 -0000 Subject: [GHC] #10721: GHC INLINE pragma behavior does not match docs In-Reply-To: <045.27a53624f8de5b0505a3ea87e28c8301@haskell.org> References: <045.27a53624f8de5b0505a3ea87e28c8301@haskell.org> Message-ID: <060.5bb3bc62035ceb2e9a63bacfb0a4b1c7@haskell.org> #10721: GHC INLINE pragma behavior does not match docs -------------------------------------+------------------------------------- Reporter: wyager | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: | specialize, inline, inlinable, | pragma Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect | (amd64) warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 15:53:53 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 15:53:53 -0000 Subject: [GHC] #10720: New GHC fails to specialize imported function In-Reply-To: <045.bc4c23e626cc82190cc1366a8178cfbb@haskell.org> References: <045.bc4c23e626cc82190cc1366a8178cfbb@haskell.org> Message-ID: <060.7a8d948d2f285c630924b04e6654b6f5@haskell.org> #10720: New GHC fails to specialize imported function -------------------------------------+------------------------------------- Reporter: wyager | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: invalid | Keywords: | performance, inline, specialize Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: I'm going to close this as fixed, but please re-open if you disagree. Thank you for a nice test case that made it easy for me to figure out what was happening. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 15:56:50 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 15:56:50 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.24dd29b14e62c32e7aee5fd8dc5d834d@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: 8317 Related Tickets: #1498 | Differential Revisions: Phab:D343 -------------------------------------+------------------------------------- Changes (by rwbarton): * Attachment "hc-nofib.txt" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 16:01:51 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 16:01:51 -0000 Subject: [GHC] #3620: The seeds generated by split are not independent In-Reply-To: <052.ef1abc8d66f675d62b108c409dd80993@haskell.org> References: <052.ef1abc8d66f675d62b108c409dd80993@haskell.org> Message-ID: <067.ef50e1a42682cc0a5704a158bd39b7ca@haskell.org> #3620: The seeds generated by split are not independent -------------------------------------+------------------------------------- Reporter: NickSmallbone | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: ? Component: Core Libraries | Version: 6.11 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate Comment: This is now being tracked in the `random` bug tracker on Github: [https://github.com/haskell/random/issues/25 The seeds generated by split are not independent]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 16:02:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 16:02:15 -0000 Subject: [GHC] #3575: mkStdGen and split conspire to make some programs predictable In-Reply-To: <047.6485fb2275f266e278f6578e798e2d4e@haskell.org> References: <047.6485fb2275f266e278f6578e798e2d4e@haskell.org> Message-ID: <062.249a502e07007a1358c5935a84e21168@haskell.org> #3575: mkStdGen and split conspire to make some programs predictable -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: ? Component: Core Libraries | Version: 6.10.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate Comment: This is now being tracked in the `random` bug tracker on Github: [https://github.com/haskell/random/issues/25 The seeds generated by split are not independent]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 16:32:04 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 16:32:04 -0000 Subject: [GHC] #10739: Resuscitate the humble ticky-ticky profiler In-Reply-To: <046.7fb5f2d03b6936365a37558b137e1612@haskell.org> References: <046.7fb5f2d03b6936365a37558b137e1612@haskell.org> Message-ID: <061.31d2fe94ce05315cf48865edae71ebc4@haskell.org> #10739: Resuscitate the humble ticky-ticky profiler -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Ticky-ticky is tremendously useful when debugging performance, because it gives repeatable counts, and it guarantees not to affect optimisation. Bringing it back up to snuff would be a Very Good Thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 16:43:13 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 16:43:13 -0000 Subject: [GHC] #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options In-Reply-To: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> References: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> Message-ID: <062.3010fd28c070714fcb6f2cb038a55350@haskell.org> #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9221, #8224 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hvr): Another use-case that comes up often is to have `-N`, but I'm not sure what kind of expression syntax to use. For instance, allow simple arithmetic expressions w/ a couple of binary functions such as `max(_,_)`, and a constant `n` denoting the number of cores detected: - `-Nmax(n,4)` - `-Ndiv(n,2)` - `-Nadd(n,-1)` or something other that's cheap/trivial to parse. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 16:59:02 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 16:59:02 -0000 Subject: [GHC] Batch modify: #322, #1307, #3927, #4139, #5728, #5762, #6124, ... Message-ID: <20150805165902.B34613A2FF@ghc.haskell.org> Batch modification to #322, #1307, #3927, #4139, #5728, #5762, #6124, #7669, #8494, #8853, #8970, #9113, #9951 by thomie: Action: resolve Comment: Because the existence of duplicate tickets makes doing a [wiki:BugSweep] of the bug tracker more cumbersome, I'm closing these tickets as duplicate. Don't worry, they're still listed on [wiki:PatternMatchCheck], and will hopefully all be addressed by the [http://git.haskell.org/ghc.git/shortlog/refs/heads/wip/gadtpm work] on #595 ("Overhaul GHC's overlapping/non-exhaustive pattern checking"). * #322 * #1307 * #3927 * #4139 * #5728 * #5762 * #6124 * #7669 * #8494 * #8853 * #8970 * #9113 * #9951 -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 17:36:37 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 17:36:37 -0000 Subject: [GHC] #5278: System.Random.randomIvalInteger makes invalid assumptions about RandomGen In-Reply-To: <047.f7f27d1475f93317cf963b728d7f9151@haskell.org> References: <047.f7f27d1475f93317cf963b728d7f9151@haskell.org> Message-ID: <062.83009c9b89c665002c0799ddb6c0c301@haskell.org> #5278: System.Random.randomIvalInteger makes invalid assumptions about RandomGen -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: ? Component: Core Libraries | Version: 7.0.3 Resolution: duplicate | Keywords: incorrect | assumption Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #8898 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #8898 Comment: This should be fixed now, see #8898. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 18:38:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 18:38:31 -0000 Subject: [GHC] #9848: List.all does not fuse In-Reply-To: <049.2f5a48f3cdf200c755c1a1e10fe7787f@haskell.org> References: <049.2f5a48f3cdf200c755c1a1e10fe7787f@haskell.org> Message-ID: <064.234fde167f2205d9109f39eb5d0ea297@haskell.org> #9848: List.all does not fuse -------------------------------------+------------------------------------- Reporter: klapaucius | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | libraries/base/tests/T9848 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * testcase: => libraries/base/tests/T9848 * resolution: => fixed * milestone: => 7.12.1 Comment: Nice [https://perf.haskell.org/ghc/#revision/22bbc1cf209d44b8bb8897ae7a35f9ebaf411b10 improvements] in nofib also: {{{ nofib/allocs/circsim 1332233568 - 4.02% 1278641568 bytes nofib/allocs/multiplier 248700640 - 8.70% 227052640 bytes }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 18:44:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 18:44:23 -0000 Subject: [GHC] #2280: randomR too slow In-Reply-To: <044.75ca98f08f0049c4dec831e20365816b@haskell.org> References: <044.75ca98f08f0049c4dec831e20365816b@haskell.org> Message-ID: <059.cc038f6738fa48ba30e428ffc133ffff@haskell.org> #2280: randomR too slow -------------------------------------+------------------------------------- Reporter: guest | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: ? Component: Core Libraries | Version: 6.8.2 Resolution: duplicate | Keywords: randomR Operating System: Linux | Architecture: x86 Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: #427 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate Comment: This bug is now being tracked in the `random` bug tracker on Github: [https://github.com/haskell/random/issues/29 randomR too slow]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 18:45:06 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 18:45:06 -0000 Subject: [GHC] #427: Random.StdGen slowness In-Reply-To: <044.910d2f7eb299e5f5b612cc8fccf049ef@haskell.org> References: <044.910d2f7eb299e5f5b612cc8fccf049ef@haskell.org> Message-ID: <059.3d4e2f788c3fc36040f29d7e86321e92@haskell.org> #427: Random.StdGen slowness -------------------------------------+------------------------------------- Reporter: remit | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: ? Component: Core Libraries | Version: Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: None => duplicate Comment: This bug is now being tracked in the `random` bug tracker on Github: [https://github.com/haskell/random/issues/28 Random.StdGen slowness]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 19:03:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 19:03:32 -0000 Subject: [GHC] #10034: Regression in mapM_ performance In-Reply-To: <045.b2f20563c81747821afdf8039fd29472@haskell.org> References: <045.b2f20563c81747821afdf8039fd29472@haskell.org> Message-ID: <060.2bb9890c811a4f7c1f3ee0303abf416d@haskell.org> #10034: Regression in mapM_ performance -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D632 -------------------------------------+------------------------------------- Changes (by bgamari): * owner: ekmett => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 19:14:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 19:14:23 -0000 Subject: [GHC] #9498: GHC links against unversioned .so files In-Reply-To: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> References: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> Message-ID: <064.bd7d18e02433d4fb99d87ad6486200f7@haskell.org> #9498: GHC links against unversioned .so files -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: trommler Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (FFI) | Version: 7.6.3 Resolution: | Keywords: Debian Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): That means we need to record the fact that `-lcurl` is necessary when linking against the static Haskell library but not when linking against the dynamic Haskell library, right? Or can we assume that this is always the case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 20:43:52 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 20:43:52 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.7320c59f784ef074c50052427e4dd9e6@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: 8317 Related Tickets: #1498 | Differential Revisions: Phab:D343 -------------------------------------+------------------------------------- Comment (by rwbarton): Attached nofib results are for the patch {{{ ; simple_scrut <- isSimpleScrut scrut alt_type ; let do_gc | not simple_scrut = True - | isSingleton alts = False - | up_hp_usg > 0 = False - | otherwise = True + | otherwise = False -- ticket:8326#comment:27 -- cf Note [Compiling case expressions] gc_plan = if do_gc then GcInAlts alt_regs else NoGcInAlts }}} As can be seen from the fact that very few Module Sizes changed, this actually rarely makes a difference. The reason is that there are two special cases of `cgCase` that always use NoGcInAlts. (I don't know why they do so, perhaps an oversight.) * If the case has algebraic alternatives, then either the scrutinee is not simple and we must GcInAlts, or the scrutinee is an application of `tagToEnum#` and the first special case applies and always uses NoGcInAlts. * If the case has primitive alternatives, then when the scrutinee is simply a variable, the second special case applies and always uses NoGcInAlts. So this patch only makes a difference when all of the following hold: * the case has primitive alternatives * the scrutinee is an application of a primop (that does not allocate, so it is simple, but most primops do not) * there is more than one alternative * there is no upstream heap check already * at least one alternative actually allocates (often CPR analysis has moved an allocation outside of the case) The combination of the second and third items is fairly rare, it means you are comparing the result of a primop against a constant. A typical example would be testing whether an Int is even or odd. Basically my conclusions are that * it's acceptable to apply this patch and always allocate outside the case here, since nofib did not find any significant regressions * it may still be worthwhile to try to make better decisions about whether to do heap checks in the alternatives, but then we should also do so in the special cases of `cgCase` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 21:04:33 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 21:04:33 -0000 Subject: [GHC] #10741: add flag to dump module and package dependencies Message-ID: <047.188005ccfe15311e6be2a08f0516bdf3@haskell.org> #10741: add flag to dump module and package dependencies -------------------------------------+------------------------------------- Reporter: elaforge | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- You can already dump module and package dependencies with -M -include-pkg- deps, but it wants to modify a Makefile, so it's not so convenient for things that are not make. For other build systems, it would be convenient to get this on stdout in an easily parseable form. Say X/A.hs imports Y/B.hs, which imports Z/C.hs, and they all use package 'base' and 'containers': {{{ % ghc -Mstdout X/A.hs X/A.h Y/B.hs Y/B.hs Z/C.hs base containers % }}} I don't know about what the output format should be, but assuming no newlines in filenames, and package names never have spaces, it seems simplest to do something like: [src ++ "\n" ++ dest ++ "\n" | (src, dest) <- moduleDeps] ++ "\n" ++ unwords packageDeps It could use haskell syntax like --info, but then you'd need a full haskell parser just to read it, which is not a problem for shake, but probably inconvenient for other build systems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 00:46:44 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 00:46:44 -0000 Subject: [GHC] #7102: Type family instance overlap accepted in ghci In-Reply-To: <044.1bce8102b22a465aacd2599a3c22a7da@haskell.org> References: <044.1bce8102b22a465aacd2599a3c22a7da@haskell.org> Message-ID: <059.d964ac4ca5f5bf08995347404be164f9@haskell.org> #7102: Type family instance overlap accepted in ghci -------------------------------------+------------------------------------- Reporter: exbb2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by oerjan): * cc: oerjan (added) * status: closed => new * resolution: wontfix => Comment: I think this behavior should be reconsidered when Safe Haskell is enabled. {{{ Prelude> :set -XSafe Prelude> :seti -XSafe Prelude> :set -XTypeFamilies Prelude> type family T a b Prelude> type instance T a b = a Prelude> let fro :: a -> T a b; fro = id Prelude> type instance T a b = b Prelude> let uc :: a -> b; uc = fro Prelude> uc 'a' :: Int 97 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 01:20:31 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 01:20:31 -0000 Subject: [GHC] #10697: Change template-haskell API to allow NOUNPACK, lazy annotations In-Reply-To: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> References: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> Message-ID: <065.11d09ca70d941df824d4356a67595bd3@haskell.org> #10697: Change template-haskell API to allow NOUNPACK, lazy annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5290, #8347 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #8347 => #5290, #8347 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 01:38:12 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 01:38:12 -0000 Subject: [GHC] #10742: GHC cannot deduce (irrelevant) reflexive type equality. Message-ID: <043.70009c4283c94391a26903bd5c00c1e8@haskell.org> #10742: GHC cannot deduce (irrelevant) reflexive type equality. -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: TypeLits | Operating System: Linux GADTs | Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- GHC is creating an irrelevant reflexive type equality and then failing to deduce it. The problem seems to be related to transitivity for `GHC.TypeLits.Nat`, as the example will make clear. Example: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeOperators #-} module TypeLitsBug where import GHC.TypeLits data T a where MkT :: T Int test :: ((x <=? y) ~ 'True, (y <=? z) ~ 'True) => proxy x y z -> () test _ = case MkT of MkT -> () }}} Error message: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.2 $ ghc -c TypeLitsBug.hs TypeLitsBug.hs:11:9: Could not deduce ((x <=? z) ~ (x <=? z)) from the context ((x <=? y) ~ 'True, (y <=? z) ~ 'True) bound by the type signature for test :: ((x <=? y) ~ 'True, (y <=? z) ~ 'True) => proxy x y z -> () at TypeLitsBug.hs:(11,9)-(12,25) NB: ?<=?? is a type function, and may not be injective }}} Notice the `x <=? z` relating `x` to `z`. I only mention `x <=? y` and `y <=? z` in the program, so it seems transitivity of `<=` is implicitly involved. Also, the problem goes away if I remove the GADT pattern match. I asked Iavor about this and he suspected the ambiguity check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 02:41:40 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 02:41:40 -0000 Subject: [GHC] #10720: New GHC fails to specialize imported function In-Reply-To: <045.bc4c23e626cc82190cc1366a8178cfbb@haskell.org> References: <045.bc4c23e626cc82190cc1366a8178cfbb@haskell.org> Message-ID: <060.9b76ec5cbe2b18e3ebee90a0633e38f6@haskell.org> #10720: New GHC fails to specialize imported function -------------------------------------+------------------------------------- Reporter: wyager | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: invalid | Keywords: | performance, inline, specialize Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by wyager): Thanks for the explanation. I am curious though; why is the specializing behavior different than it was in the previous Haskell-platform's GHC? Did it start to specialize less aggressively? Will -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 03:27:42 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 03:27:42 -0000 Subject: [GHC] #10743: Data declaration order matters to compiler. Message-ID: <050.55c9cdf93079f3f066d7c993fe71d005@haskell.org> #10743: Data declaration order matters to compiler. -------------------------------------+------------------------------------- Reporter: | Owner: thomaseding | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{ {-# LANGUAGE GADTs #-} {-# LANGUAGE TemplateHaskell #-} import Control.Lens.TH (makeLenses) data Handle h where PlayerHandle :: Int -> Handle Player -- GHC 7.8.3 complains that NonPlayer is not in scope NonPlayerHandle :: Int -> Handle NonPlayer data Player = Player -- Deferring this until after NonPlayer is defined, resolves the compile error. -- Commenting this out also works. makeLenses ''Player data NonPlayer }}} (The exact version of 'lens' I have tried this with is 'lens-4.7' if that matters.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 05:55:25 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 05:55:25 -0000 Subject: [GHC] #9498: GHC links against unversioned .so files In-Reply-To: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> References: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> Message-ID: <064.61d604a971895f892378a7111847820a@haskell.org> #9498: GHC links against unversioned .so files -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (FFI) | Version: 7.6.3 Resolution: | Keywords: Debian Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by trommler): * owner: trommler => Comment: Replying to [comment:9 rwbarton]: > That means we need to record the fact that `-lcurl` is necessary when linking against the static Haskell library but not when linking against the dynamic Haskell library, right? You are right, the dynamic library is linked against the versioned C library and no extra `-lcurl` is required. At build time we need the development package for libcurl so the link editor (ld) can link the dynamic Haskell library. To use the dynamic Haskell library the unversioned library is not needed anymore. To load a static library we use the RTS linker and the RTS linker needs to load dependent C libraries explicitly. Unfortunately we cannot assume that the C library with a specific version is installed. So the RTS linker looks for the unversioned library and tries to load that. So yes, the unversioned C library is currently necessary to load a static Haskell library but not needed to load a dynamic Haskell library. Perhaps we could make cabal record the version information for C libraries in the package database as suggested in comment:8 and change the RTS linker to use that information? I don't have time to work on this now, so I am disowning the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 07:04:44 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 07:04:44 -0000 Subject: [GHC] #10742: GHC cannot deduce (irrelevant) reflexive type equality. In-Reply-To: <043.70009c4283c94391a26903bd5c00c1e8@haskell.org> References: <043.70009c4283c94391a26903bd5c00c1e8@haskell.org> Message-ID: <058.b053d0a7ad58ffc4e3c598c0683fe3e0@haskell.org> #10742: GHC cannot deduce (irrelevant) reflexive type equality. -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Keywords: TypeLits Resolution: | GADTs Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * os: Linux => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple Comment: Fwiw, ghc HEAD reports: {{{ $ ghc-7.11.20150805 Test.hs [1 of 1] Compiling TypeLitsBug ( Test.hs, Test.o ) Test.hs:11:9: warning: Redundant constraints: ((x <=? y) ~ 'True, (y <=? z) ~ 'True) In the type signature for: test :: ((x <=? y) ~ 'True, (y <=? z) ~ 'True) => proxy x y z -> () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 07:40:02 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 07:40:02 -0000 Subject: [GHC] #9498: GHC links against unversioned .so files In-Reply-To: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> References: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> Message-ID: <064.9831fa26e2cf1554f0cb6b07a71e31f5@haskell.org> #9498: GHC links against unversioned .so files -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (FFI) | Version: 7.6.3 Resolution: | Keywords: Debian Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): > To load a static library we use the RTS linker and the RTS linker needs to load dependent C libraries explicitly. Unfortunately we cannot assume that the C library with a specific version is installed. So the RTS linker looks for the unversioned library and tries to load that. BTW, why is that? Is it a valid and supported use case to build against one version and run against another version of the library? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 07:55:26 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 07:55:26 -0000 Subject: [GHC] #10738: Make Exception datatypes into newtypes In-Reply-To: <050.5d465a0cdfbff2328b1c7589102aa667@haskell.org> References: <050.5d465a0cdfbff2328b1c7589102aa667@haskell.org> Message-ID: <065.f046322ee8ce7c8c3904f9409169ad6b@haskell.org> #10738: Make Exception datatypes into newtypes -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4961 | Differential Revisions: Phab:D1131 -------------------------------------+------------------------------------- Changes (by thomie): * status: closed => new * owner: RyanGlScott => * resolution: fixed => Comment: This caused a performance regression, see https://perf.haskell.org/ghc/#revision/b12dba7829742de98a483645142c7962b9dd9f3f {{{ nofib/time/cryptarithm1 0.374 + 7.22% 0.401 seconds }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 09:00:52 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 09:00:52 -0000 Subject: [GHC] #10743: Data declaration order matters to compiler. In-Reply-To: <050.55c9cdf93079f3f066d7c993fe71d005@haskell.org> References: <050.55c9cdf93079f3f066d7c993fe71d005@haskell.org> Message-ID: <065.f105657f534824acfef73afd4c112d58@haskell.org> #10743: Data declaration order matters to compiler. -------------------------------------+------------------------------------- Reporter: thomaseding | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: Windows | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => invalid Comment: This is (arguably unfortunately) the expected behavior. See the discussion of "declaration groups" in [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/template- haskell.html Section 7.17.1] of the User's Guide. In short, splices delimit groups of declarations. Declarations can only be recursive within their group. The usual solution here would be to move the `makeLenses` splice after the `data NonPlayer` definition. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 09:14:25 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 09:14:25 -0000 Subject: [GHC] #10720: New GHC fails to specialize imported function In-Reply-To: <045.bc4c23e626cc82190cc1366a8178cfbb@haskell.org> References: <045.bc4c23e626cc82190cc1366a8178cfbb@haskell.org> Message-ID: <060.1abc1db0908323deaa95f4183240d5e9@haskell.org> #10720: New GHC fails to specialize imported function -------------------------------------+------------------------------------- Reporter: wyager | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: invalid | Keywords: | performance, inline, specialize Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Replying to [comment:5 wyager]: > why is the specializing behavior different than it was in the previous Haskell-platform's GHC? Did it start to specialize less aggressively? I'm afraid I don't know -- and I am reluctant to invest the time in finding out. But that shouldn't stand in the way of someone else looking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 09:57:30 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 09:57:30 -0000 Subject: [GHC] #10034: Regression in mapM_ performance In-Reply-To: <045.b2f20563c81747821afdf8039fd29472@haskell.org> References: <045.b2f20563c81747821afdf8039fd29472@haskell.org> Message-ID: <060.7fcfdbec03f39f4405de2a86f7bc942a@haskell.org> #10034: Regression in mapM_ performance -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D632 -------------------------------------+------------------------------------- Comment (by bgamari): David, I don't suppose you have stumbled upon an example of this in the months, have you? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 10:27:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 10:27:08 -0000 Subject: [GHC] #10457: Revise/remove custom mapM implementation for lists In-Reply-To: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> References: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> Message-ID: <059.75538576d85ae13a0841a8b57f35376c@haskell.org> #10457: Revise/remove custom mapM implementation for lists -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1124 -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * resolution: fixed => Comment: The [https://perf.haskell.org/ghc/#revision/60297486fddd5c9695e2263c2ae46fa90f0feb9e perf tester says], about nofib allocations: {{{ nofib/allocs/cryptarithm2 + 64.55% nofib/allocs/k-nucleotide - 5.03% nofib/time/fannkuch-redux - 3.62% }}} This needs looking into! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 11:57:40 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 11:57:40 -0000 Subject: [GHC] #10744: Allow oneShot to work with unboxed types Message-ID: <043.1a18f79737236ccee17a4841dc4bdcd8@haskell.org> #10744: Allow oneShot to work with unboxed types -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Currently `oneShot` requires that both the argument type and the return type of the given function have the kind `*`. It would be nice if I could use unlifted types there. The following program demonstrates this: {{{#!hs {-# LANGUAGE MagicHash #-} module Foo where import GHC.Exts import GHC.Magic f0 :: Int -> Int f0 = oneShot $ \n -> n -- OK f1 :: Int# -> Int f1 = oneShot $ \n# -> I# n# -- Error, the argument type is unlifted f2 :: Int -> Int# f2 = oneShot $ \(I# n#) -> n# -- Error, the result type is unlifted }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 12:00:41 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 12:00:41 -0000 Subject: [GHC] #10745: Error in fusion when compiling Data.Yaml Message-ID: <046.37d8d5c0695542a7552f6e9c30a12ec8@haskell.org> #10745: Error in fusion when compiling Data.Yaml -----------------------------------------+--------------------------------- Reporter: nclarke | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+--------------------------------- {{{ [2 of 7] Compiling Data.Yaml.Internal ( Data/Yaml/Internal.hs, dist/dist- sandbox-b22ce51e/build/Data/Yaml/Internal.o ) Data/Yaml/Internal.hs:28:1: Warning: The import of ?Control.Applicative? is redundant except perhaps to import instances from ?Control.Applicative? To import instances alone, use: import Control.Applicative() ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): Tick in rule unstream @ a34_ayco @ Void @ m_aycm @ b_aycn (ConduitWithStream @ a34_ayco @ Void @ m_aycm @ b_aycn (let { $dApplicative_aycu :: Applicative (ConduitM a34_ayco Void m_aycm) [LclId, Str=DmdType] $dApplicative_aycu = $fApplicativeConduitM @ a34_ayco @ Void @ m_aycm ($fFunctorConduitM @ a34_ayco @ Void @ m_aycm) } in letrec { loop_aycv :: b_aycn -> ConduitM a34_ayco Void m_aycm b_aycn [LclId, Arity=1, Str=DmdType] loop_aycv = \ (accum_aycw :: b_aycn) -> $fMonadConduitM_$c>>= @ a34_ayco @ Void @ m_aycm $dApplicative_aycu @ (Maybe a34_ayco) @ b_aycn ((await @ a34_ayco @ m_aycm $dMonad1_aycq) @ Void) (maybe @ (ConduitM a34_ayco Void m_aycm b_aycn) @ a34_ayco ($fMonadConduitM_$creturn @ a34_ayco @ Void @ m_aycm $dApplicative_aycu @ b_aycn accum_aycw) (\ (a35_aycx :: a34_ayco) -> $fMonadConduitM_$c>>= @ a34_ayco @ Void @ m_aycm $dApplicative_aycu @ b_aycn @ b_aycn ($ @ (m_aycm b_aycn) @ (ConduitM a34_ayco Void m_aycm b_aycn) ($fMonadBasebaseConduitM_$clift @ a34_ayco @ Void @ m_aycm @ b_aycn $dMonad1_aycq) (f_aycs accum_aycw a35_aycx)) (\ (accum'_aycy :: b_aycn) -> case accum'_aycy of wild_aycz { __DEFAULT -> loop_aycv wild_aycz }))); } in loop_aycv b1_ayct) (foldMS @ b_aycn @ a34_ayco @ m_aycm $dMonad1_aycq f_aycs b1_ayct @ Void)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 12:05:31 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 12:05:31 -0000 Subject: [GHC] #10744: Allow oneShot to work with unboxed types In-Reply-To: <043.1a18f79737236ccee17a4841dc4bdcd8@haskell.org> References: <043.1a18f79737236ccee17a4841dc4bdcd8@haskell.org> Message-ID: <058.e7b9d9b2e3a513ce04c4eef27289eb84@haskell.org> #10744: Allow oneShot to work with unboxed types -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * cc: nomeata (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 12:26:16 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 12:26:16 -0000 Subject: [GHC] #10744: Allow oneShot to work with unboxed types In-Reply-To: <043.1a18f79737236ccee17a4841dc4bdcd8@haskell.org> References: <043.1a18f79737236ccee17a4841dc4bdcd8@haskell.org> Message-ID: <058.fc42950a165c0f8d051bb1ba15a61f8f@haskell.org> #10744: Allow oneShot to work with unboxed types -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Out of curiosity: How are you using `oneShot`? We added it to make foldl list fusion more reliable, but never actually had a case where it would be better than Call Arity, so I am very interested in examples of effective uses of `oneShot`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 12:28:45 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 12:28:45 -0000 Subject: [GHC] #10736: threadWaitRead/registerFd unusable In-Reply-To: <044.a96ce04f26395251bc71867625bc2939@haskell.org> References: <044.a96ce04f26395251bc71867625bc2939@haskell.org> Message-ID: <059.cbbc3a6ec5bf8dccb488d06dc075dac8@haskell.org> #10736: threadWaitRead/registerFd unusable -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by mboes): I see! That makes sense. So shall we close this ticket and open a new one for documentation? What we want to document here I'm guessing is simply that the behaviour of registerFd is system dependent, and that some systems might impose restrictions on the types of FD that work and ones that do not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 12:29:19 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 12:29:19 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.40fc2472802431a3a6cd8ba5533725e7@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: 8317 Related Tickets: #1498 | Differential Revisions: Phab:D343 -------------------------------------+------------------------------------- Comment (by simonpj): Terrific. Could you try the effect of re-enabling the fix in [ticket:8317#comment:2]. The code is still in `Simplify.hs`, just commented out. Look for "Disabled until we fix #8326". If that works (no perf cost, no binary size increase), then the next step is to remove the special case `Note [case on bool]` in `StgCmmExpr`; it will never be used because the `Simplify` change will catch the case first. Might you try those two steps? Thanks! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 12:35:34 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 12:35:34 -0000 Subject: [GHC] #10745: Error in fusion when compiling Data.Yaml In-Reply-To: <046.37d8d5c0695542a7552f6e9c30a12ec8@haskell.org> References: <046.37d8d5c0695542a7552f6e9c30a12ec8@haskell.org> Message-ID: <061.08db0c670ddab13e5be774d24f3fb51f@haskell.org> #10745: Error in fusion when compiling Data.Yaml ---------------------------------+----------------------------------------- Reporter: nclarke | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10665 | Differential Revisions: ---------------------------------+----------------------------------------- Changes (by thomie): * status: new => infoneeded * related: => #10665 Comment: I can't reproduce this. I am assuming you are trying to run `cabal install yaml` with ghc-7.10.2. This worked for me, but I might have different versions of dependencies installed than you. Can you give the exact command(s) you are running that will fail when run in a cabal sandbox, after temporarily renaming your .cabal/config file to something else. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 12:37:23 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 12:37:23 -0000 Subject: [GHC] #10745: Error in fusion when compiling Data.Yaml In-Reply-To: <046.37d8d5c0695542a7552f6e9c30a12ec8@haskell.org> References: <046.37d8d5c0695542a7552f6e9c30a12ec8@haskell.org> Message-ID: <061.db59a0ab7a97675ec42503da0a9ef75f@haskell.org> #10745: Error in fusion when compiling Data.Yaml ---------------------------------+----------------------------------------- Reporter: nclarke | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Changes (by bgamari): * related: #10665 => Comment: Interesting but I have been unable to reproduce this locally. What version of `yaml` is this? Perhaps you could paste the output of `cabal install -n -v3 yaml` so we can document which dependencies are being pulled in here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 12:37:28 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 12:37:28 -0000 Subject: [GHC] #10665: INLINE breaks rewrite rules when '-g' is used In-Reply-To: <045.95657d2fca941df9621daef19a7fe710@haskell.org> References: <045.95657d2fca941df9621daef19a7fe710@haskell.org> Message-ID: <060.4c183803a394bae24e04278f9e114a26@haskell.org> #10665: INLINE breaks rewrite rules when '-g' is used -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2-rc2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * milestone: => 7.10.3 Comment: I believe this is fixed by {{{ commit bc4b64ca5b99bff6b3d5051b57cb2bc52bd4c841 Author: Simon Peyton Jones Date: Mon Jul 27 13:56:31 2015 +0100 Do not inline or apply rules on LHS of rules This is the right thing to do anyway, and fixes Trac #10528 }}} Trac #10745 is probably another example. Perhaps merge to 7.10.3. Meanwhile, can you confirm fixed in HEAD? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 12:38:14 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 12:38:14 -0000 Subject: [GHC] #10745: Error in fusion when compiling Data.Yaml In-Reply-To: <046.37d8d5c0695542a7552f6e9c30a12ec8@haskell.org> References: <046.37d8d5c0695542a7552f6e9c30a12ec8@haskell.org> Message-ID: <061.27694cb97a3d32d835046a2db3b6f783@haskell.org> #10745: Error in fusion when compiling Data.Yaml ---------------------------------+----------------------------------------- Reporter: nclarke | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Changes (by simonpj): * status: infoneeded => merge * milestone: => 7.10.3 Comment: I believe this is fixed by {{{ commit bc4b64ca5b99bff6b3d5051b57cb2bc52bd4c841 Author: Simon Peyton Jones Date: Mon Jul 27 13:56:31 2015 +0100 Do not inline or apply rules on LHS of rules This is the right thing to do anyway, and fixes Trac #10528 }}} Trac #10665 is probably another example. Perhaps merge to 7.10.3. Meanwhile, can you confirm fixed in HEAD? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 12:41:03 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 12:41:03 -0000 Subject: [GHC] #10745: Error in fusion when compiling Data.Yaml In-Reply-To: <046.37d8d5c0695542a7552f6e9c30a12ec8@haskell.org> References: <046.37d8d5c0695542a7552f6e9c30a12ec8@haskell.org> Message-ID: <061.110c36ccaf41499a4dac98bd55856a4f@haskell.org> #10745: Error in fusion when compiling Data.Yaml ---------------------------------+----------------------------------------- Reporter: nclarke | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Changes (by nclarke): * milestone: 7.10.3 => Comment: I got this on both `0.8.11` and `0.8.12`, but I likewise have been unable to reproduce in a fresh sandbox. It happened consistently when building in one particular sandbox, and I'm surprised that the compiler was doing was being affected by this, but apparently it was. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 12:45:19 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 12:45:19 -0000 Subject: [GHC] #7102: Type family instance overlap accepted in ghci In-Reply-To: <044.1bce8102b22a465aacd2599a3c22a7da@haskell.org> References: <044.1bce8102b22a465aacd2599a3c22a7da@haskell.org> Message-ID: <059.0232f82be37b74232e3cc19c71fa9fc4@haskell.org> #7102: Type family instance overlap accepted in ghci -------------------------------------+------------------------------------- Reporter: exbb2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): That is indeed very very bad. Never mind Safe Haskell -- it's just unsound. You didn't get a seg fault, but you very well might have. (For class instances it wouldn't be unsound, just possibly a bit incoherent.) I'm not sure what to do: 1. Prohibit `type instance` declarations in GHCi that overlap/override earlier ones? 2. Do (1) but also provide a way to purge the GHCi environment, so you can get back to a clean slate without restarting GHCi 3. Try to be clever: purge only functions (or whatever) whose types mention `T`. But it's tricky: what about data types mentioning `T`, and functions whose types use those data types... I incline to (2). Any other opinions? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 12:46:27 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 12:46:27 -0000 Subject: [GHC] #9953: Pattern synonyms don't work with GADTs In-Reply-To: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> References: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> Message-ID: <061.137c0c1dc042c9c663d1e9d07c1b57a8@haskell.org> #9953: Pattern synonyms don't work with GADTs -------------------------------------+------------------------------------- Reporter: simonpj | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: fixed | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): It appears that there are still two tests marked as broken due to this issue (`T8968-1` and `T8968-3`). They appear to be fixed by either 28096b274a3803b8a479c5dd94ebda655a15566c or 953648127cea2836ec134b03a966695ac0b36434 (both commits by Simon PJ). Simon, is this an expected consequence of this rework? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 12:50:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 12:50:33 -0000 Subject: [GHC] #9953: Pattern synonyms don't work with GADTs In-Reply-To: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> References: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> Message-ID: <061.8dc69541020727419ed564ae68298969@haskell.org> #9953: Pattern synonyms don't work with GADTs -------------------------------------+------------------------------------- Reporter: simonpj | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: fixed | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I'm looking at it; it's tricky stuff. Meanwhile, you could make validate work again, opening a ticket for this issue, so that everyone else was not inconvenienced. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 12:58:05 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 12:58:05 -0000 Subject: [GHC] #10745: Error in fusion when compiling Data.Yaml In-Reply-To: <046.37d8d5c0695542a7552f6e9c30a12ec8@haskell.org> References: <046.37d8d5c0695542a7552f6e9c30a12ec8@haskell.org> Message-ID: <061.fc02b7edcaf88a66accfe7ed9283ae1f@haskell.org> #10745: Error in fusion when compiling Data.Yaml ---------------------------------+----------------------------------------- Reporter: nclarke | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Changes (by nclarke): * milestone: => 7.10.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 13:01:53 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 13:01:53 -0000 Subject: [GHC] #9953: Pattern synonyms don't work with GADTs In-Reply-To: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> References: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> Message-ID: <061.33144ecfc24913c9303445afe7941837@haskell.org> #9953: Pattern synonyms don't work with GADTs -------------------------------------+------------------------------------- Reporter: simonpj | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: fixed | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): The real question is why were these tests marked as broken against a closed ticket? Are they actually expected to work? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 13:43:54 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 13:43:54 -0000 Subject: [GHC] #9953: Pattern synonyms don't work with GADTs In-Reply-To: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> References: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> Message-ID: <061.b4b2c91f4959819cb47add9f6d43d469@haskell.org> #9953: Pattern synonyms don't work with GADTs -------------------------------------+------------------------------------- Reporter: simonpj | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: fixed | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): OK. I believe the "expect-broken" is because we get (odd-looking) error {{{ T8968-1.hs:8:9: warning: Redundant constraint: Maybe a ~ Maybe a In the type signature for: C :: a -> X Maybe (Maybe a) }}} Now one of the minor changes in {{{ commit 953648127cea2836ec134b03a966695ac0b36434 Author: Simon Peyton Jones Date: Wed Aug 5 14:24:54 2015 +0100 Tidy up and refactor wildcard handling }}} was to add a new `UserTypeCtxt` for pattern synonyms, namely `PatSynCtxt`. Previously I used `FunSigCtxt`. Then in `TcSimplify.warnRedundantGivens` I treat `PatSynCtxt` (like most others) as "do't report redundant constraints". So the behaviour changes: redundant constraints are no longer reported for pattern synonyms. So, just remove the expect-broken; it's fine for them to pass. I suppose that warning abour redundant constraints in pattern-synonym signatures might be a good thing, but that's a battle for another day. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 13:50:12 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 13:50:12 -0000 Subject: [GHC] #9953: Pattern synonyms don't work with GADTs In-Reply-To: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> References: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> Message-ID: <061.7d2c2e581fbf316990d9416420b30781@haskell.org> #9953: Pattern synonyms don't work with GADTs -------------------------------------+------------------------------------- Reporter: simonpj | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: fixed | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"294553e960404bf9765eae6891b5800ae5127879/ghc" 294553e9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="294553e960404bf9765eae6891b5800ae5127879" T8968-1 and -3 should pass See Trac #9953, comment:22. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 13:50:12 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 13:50:12 -0000 Subject: [GHC] #10742: GHC cannot deduce (irrelevant) reflexive type equality. In-Reply-To: <043.70009c4283c94391a26903bd5c00c1e8@haskell.org> References: <043.70009c4283c94391a26903bd5c00c1e8@haskell.org> Message-ID: <058.d1f3993b26cfad97fa933d557e3d044a@haskell.org> #10742: GHC cannot deduce (irrelevant) reflexive type equality. -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Keywords: TypeLits Resolution: | GADTs Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"64dba5119fdecb4a5b6a2993919a963d02171783/ghc" 64dba51/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="64dba5119fdecb4a5b6a2993919a963d02171783" Test Trac #10742 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 13:51:35 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 13:51:35 -0000 Subject: [GHC] #10742: GHC cannot deduce (irrelevant) reflexive type equality. In-Reply-To: <043.70009c4283c94391a26903bd5c00c1e8@haskell.org> References: <043.70009c4283c94391a26903bd5c00c1e8@haskell.org> Message-ID: <058.347ef24d567ac0b4b60326161cf8df7f@haskell.org> #10742: GHC cannot deduce (irrelevant) reflexive type equality. -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Keywords: TypeLits Resolution: | GADTs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T10742 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => polykinds/T10742 Comment: Since it works in HEAD, I'm inclined to close this and move on. Unless it is causing real pain that 7.10.2 doesn't work. I've added a regression test though, to make sure it stays working! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 14:40:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 14:40:06 -0000 Subject: [GHC] #10746: No non-exhaustive pattern match warning given for empty case analysis Message-ID: <046.7124d47aa8c745a5f8757fe53c21a64c@haskell.org> #10746: No non-exhaustive pattern match warning given for empty case analysis -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I would expect GHC to warn of a non-exhaustive pattern match at compile- time when faced with this, {{{#!hs {-# LANGUAGE EmptyCase #-} module Test where test :: Bool -> Int test a = case a of }}} Yet it happily accepts this without complaint. If one attempts to evaluate, e.g., `test True` the expected "Non-exhaustive patterns in case" error is thrown at runtime. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 15:01:53 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 15:01:53 -0000 Subject: [GHC] #10725: Figure out how to support type synonym implementions of abstract data In-Reply-To: <045.980e660de8478100fba0b108c0422308@haskell.org> References: <045.980e660de8478100fba0b108c0422308@haskell.org> Message-ID: <060.0c1f2613ec0f811723bb738aa445e650@haskell.org> #10725: Figure out how to support type synonym implementions of abstract data -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by skilpat): * cc: skilpat (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 15:06:01 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 15:06:01 -0000 Subject: [GHC] #10746: No non-exhaustive pattern match warning given for empty case analysis In-Reply-To: <046.7124d47aa8c745a5f8757fe53c21a64c@haskell.org> References: <046.7124d47aa8c745a5f8757fe53c21a64c@haskell.org> Message-ID: <061.9d94116db18ba53579466618eed27992@haskell.org> #10746: No non-exhaustive pattern match warning given for empty case analysis -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #7669 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #7669 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 15:10:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 15:10:06 -0000 Subject: [GHC] #10746: No non-exhaustive pattern match warning given for empty case analysis In-Reply-To: <046.7124d47aa8c745a5f8757fe53c21a64c@haskell.org> References: <046.7124d47aa8c745a5f8757fe53c21a64c@haskell.org> Message-ID: <061.501820e8ba673b8d55d12a20061b9633@haskell.org> #10746: No non-exhaustive pattern match warning given for empty case analysis -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #7669 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => new * resolution: duplicate => Comment: To be clear, the problem here is that we *are* in fact missing cases in the example cited above. In the case of #7669 the compiler was complaining despite the fact that the user cannot provide any cases (as we are matching against an empty type). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 15:16:50 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 15:16:50 -0000 Subject: [GHC] #10746: No non-exhaustive pattern match warning given for empty case analysis In-Reply-To: <046.7124d47aa8c745a5f8757fe53c21a64c@haskell.org> References: <046.7124d47aa8c745a5f8757fe53c21a64c@haskell.org> Message-ID: <061.7befd6d95f2cd36b4e77471e1b1c525d@haskell.org> #10746: No non-exhaustive pattern match warning given for empty case analysis -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #7669 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate Comment: Ahh, in the interest of aiding the bug sweep (see ticket:7669#comment:8) I'll leave this as a duplicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 15:28:36 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 15:28:36 -0000 Subject: [GHC] #10747: Infix pattern synonyms fail to parse (regression) Message-ID: <048.dc77b17374ac8b11e33228cc9dd19430@haskell.org> #10747: Infix pattern synonyms fail to parse (regression) -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE PatternSynonyms #-} pattern head `Cons` tail = head : tail }}} In v7.11 I get: {{{ [1 of 1] Compiling Main ( pat.hs, interpreted ) pat.hs:2:14: parse error on input ?`? }}} In v7.10 I get: {{{ *Main> :set -XPatternSynonyms *Main> let h `Cons` t = "ht" *Main> h 'h' *Main> t "t" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 15:42:26 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 15:42:26 -0000 Subject: [GHC] #10744: Allow oneShot to work with unboxed types In-Reply-To: <043.1a18f79737236ccee17a4841dc4bdcd8@haskell.org> References: <043.1a18f79737236ccee17a4841dc4bdcd8@haskell.org> Message-ID: <058.c5b15e63c2e6ee86a60e2d89d7379f40@haskell.org> #10744: Allow oneShot to work with unboxed types -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by akio): I use it in the fast-builder package [1], which aims to be a ByteString builder implementation that is significantly faster than the standard one. The main Builder type looks like this {{{#!hs type Builder = DataSink -> State -> State data DataSink = -- abstract data State = -- abstract -- | Builder concatenation. (<>) :: Builder -> Builder -> Builder a <> b = \sink s = b sink (a sink s) -- | Primitive builder. int :: Int -> Builder int = -- implementation omitted. }}} As an example, the user may write code like this to serialize a list of Ints: {{{#!hs serialize :: [Int] -> Builder serialize list = int (length list) <> foldr (<>) mempty (map int list) }}} For `serialize` to work efficiently, I really want it to have the arity of 3. However, simply inlining `int` and `(<>)` only gives {{{#!hs serialize = \list -> let len = length list in \sink s -> ... }}} So it gets arity 1, which means it has to allocate a lambda and then call it. By default GHC doesn't eta-expand `serialize` because it wants to avoid evaluating `length` multiple times. However, I want GHC to produce better code in the assumption that the resulting Builder will be used at most once, because using the same Builder multiple times is usually a bad idea anyway (you should instead turn it into a ByteString and use that ByteString multiple times). I express this preference by inserting calls to `oneShot` into the definitions of `(<>)`, `int`, etc. The current type of `oneShot` means `State` has to be a lifted type. Ideally I'd like to use something like `(# Addr#, Addr#, State# RealWorld #)`. [1]: http://hackage.haskell.org/package/fast-builder -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 15:46:53 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 15:46:53 -0000 Subject: [GHC] #10745: Error in fusion when compiling Data.Yaml In-Reply-To: <046.37d8d5c0695542a7552f6e9c30a12ec8@haskell.org> References: <046.37d8d5c0695542a7552f6e9c30a12ec8@haskell.org> Message-ID: <061.c16841e51145beb3add8b0550aa3ce60@haskell.org> #10745: Error in fusion when compiling Data.Yaml ---------------------------------+----------------------------------------- Reporter: nclarke | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by rwbarton): Do you still have the failing sandbox? If so can you try `cabal build --ghc-option=-dppr-ticks`? There are a few different kinds of ticks and knowing which kind it is might reveal what is special about your sandbox (e.g. profiling or HPC or debugging information is turned on). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 15:56:36 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 15:56:36 -0000 Subject: [GHC] #10747: Infix pattern synonyms fail to parse (regression) In-Reply-To: <048.dc77b17374ac8b11e33228cc9dd19430@haskell.org> References: <048.dc77b17374ac8b11e33228cc9dd19430@haskell.org> Message-ID: <063.c5e73e5505601284f377ab6c27fd2df5@haskell.org> #10747: Infix pattern synonyms fail to parse (regression) -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Are you sure about the version numbers? I see it working in 7.8, but failing in 7.10 and HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 16:01:27 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 16:01:27 -0000 Subject: [GHC] #10549: floatExpr tick break<2> In-Reply-To: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> References: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> Message-ID: <066.5d3943d9dd1172ae0246297a25928b01@haskell.org> #10549: floatExpr tick break<2> -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T10549 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1128 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"eca9a1a17c12d01636417fb88bda5ee5fe34577f/ghc" eca9a1a1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="eca9a1a17c12d01636417fb88bda5ee5fe34577f" Ensure DynFlags are consistent While we have always had makeDynFlagsConsistent to enforce a variety of consistency invariants on DynFlags, it hasn't been widely used. GHC.Main, for instance, ignored it entirely. This leads to issues like Trac #10549, where an OPTIONS_GHC pragma introduced an inconsistency, leading to a perplexing crash later in compilation. Here I add consistency checks in GHC.Main.set{Session,Program}DynFlags, closing this hole. Fixes #10549. Test Plan: Validate with T10549 Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1128 GHC Trac Issues: #10549 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 16:01:28 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 16:01:28 -0000 Subject: [GHC] #10394: LLVM mangler doesn't mangle AVX instructions In-Reply-To: <047.b85b8723ab1fa78e7e23f08be8ccae23@haskell.org> References: <047.b85b8723ab1fa78e7e23f08be8ccae23@haskell.org> Message-ID: <062.a4b929d746d4b614cd6cbfc7b14a98b8@haskell.org> #10394: LLVM mangler doesn't mangle AVX instructions -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler (LLVM) | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1034 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"600b153abb78505911db8b0c44e6f172f6ddb18f/ghc" 600b153a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="600b153abb78505911db8b0c44e6f172f6ddb18f" llvmGen: Rework LLVM mangler The LLVM mangler does not currently transform AVX instructions on x86-64 platforms, due to a missing #include. Also, it is significantly more complicated than necessary, due to the file into sections (not needed anymore), and is sensitive to the details of the whitespace in the assembly. Author: dobenour Test Plan: Validation on x86-64, x86-32, and ARM Reviewers: austin Subscribers: thomie, bgamari, rwbarton Differential Revision: https://phabricator.haskell.org/D1034 GHC Trac Issues: #10394 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 16:01:28 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 16:01:28 -0000 Subject: [GHC] #10609: Make up instances In-Reply-To: <047.ffaf9fde9cde45ea3283521ce42e1f8c@haskell.org> References: <047.ffaf9fde9cde45ea3283521ce42e1f8c@haskell.org> Message-ID: <062.cad7c5a1215239f4c19ae10be92c8f11@haskell.org> #10609: Make up instances -------------------------------------+------------------------------------- Reporter: fumieval | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1049 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"97843d0b10cac3912a85329ebcb8ed1a68f71b34/ghc" 97843d0b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="97843d0b10cac3912a85329ebcb8ed1a68f71b34" base: Add instances This patch adds following instances: * Foldable ZipList * Traversable ZipList * Functor Complex * Applicative Complex * Monad Complex * Foldable Complex * Traversable Complex * Generic1 Complex * Monoid a => Monoid (Identity a) * Storable () Reviewers: ekmett, fumieval, hvr, austin Subscribers: thomie, #core_libraries_committee Projects: #core_libraries_committee Differential Revision: https://phabricator.haskell.org/D1049 GHC Trac Issues: #10609 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 16:01:56 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 16:01:56 -0000 Subject: [GHC] #10746: No non-exhaustive pattern match warning given for empty case analysis In-Reply-To: <046.7124d47aa8c745a5f8757fe53c21a64c@haskell.org> References: <046.7124d47aa8c745a5f8757fe53c21a64c@haskell.org> Message-ID: <061.0b33281b0a4760eb9c13c76bae9da4ab@haskell.org> #10746: No non-exhaustive pattern match warning given for empty case analysis -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #7669 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): It's a duplicate of ticket:7669#comment:3, not the original bug report in #7669. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 16:02:16 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 16:02:16 -0000 Subject: [GHC] #10747: Infix pattern synonyms fail to parse (regression) In-Reply-To: <048.dc77b17374ac8b11e33228cc9dd19430@haskell.org> References: <048.dc77b17374ac8b11e33228cc9dd19430@haskell.org> Message-ID: <063.3d9a5eb53134a041f217722c08f865f4@haskell.org> #10747: Infix pattern synonyms fail to parse (regression) -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by heisenbug): Replying to [comment:1 rwbarton]: > Are you sure about the version numbers? I see it working in 7.8, but failing in 7.10 and HEAD. Ooops, no. Actually I was using a v7.9-201411xx for the test. Sorry for the wrong interpolation :-( -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 16:03:51 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 16:03:51 -0000 Subject: [GHC] #10747: Infix pattern synonyms fail to parse (regression) In-Reply-To: <048.dc77b17374ac8b11e33228cc9dd19430@haskell.org> References: <048.dc77b17374ac8b11e33228cc9dd19430@haskell.org> Message-ID: <063.2ce1ad5532ce845e2c726a72a276be58@haskell.org> #10747: Infix pattern synonyms fail to parse (regression) -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * priority: normal => high * version: 7.11 => 7.10.1 Old description: > {{{#!hs > {-# LANGUAGE PatternSynonyms #-} > pattern head `Cons` tail = head : tail > }}} > > In v7.11 I get: > {{{ > [1 of 1] Compiling Main ( pat.hs, interpreted ) > > pat.hs:2:14: parse error on input ?`? > > }}} > > In v7.10 I get: > {{{ > *Main> :set -XPatternSynonyms > *Main> let h `Cons` t = "ht" > *Main> h > 'h' > *Main> t > "t" > }}} New description: {{{#!hs {-# LANGUAGE PatternSynonyms #-} pattern head `Cons` tail = head : tail }}} In v7.10 I get: {{{ [1 of 1] Compiling Main ( pat.hs, interpreted ) pat.hs:2:14: parse error on input ?`? }}} In v7.8 I get: {{{ [1 of 1] Compiling Main ( ph.hs, interpreted ) Ok, modules loaded: Main. *Main> :set -XPatternSynonyms *Main> let h `Cons` t = "ht" *Main> h 'h' *Main> t "t" }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 16:09:46 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 16:09:46 -0000 Subject: [GHC] #10609: Make up instances In-Reply-To: <047.ffaf9fde9cde45ea3283521ce42e1f8c@haskell.org> References: <047.ffaf9fde9cde45ea3283521ce42e1f8c@haskell.org> Message-ID: <062.80a1c6fa17d25febc0f9959f7a0bd93c@haskell.org> #10609: Make up instances -------------------------------------+------------------------------------- Reporter: fumieval | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1049 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 16:09:53 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 16:09:53 -0000 Subject: [GHC] #10549: floatExpr tick break<2> In-Reply-To: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> References: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> Message-ID: <066.80e6d321d567bfba3b02bee38fdf9fb4@haskell.org> #10549: floatExpr tick break<2> -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T10549 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1128 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 16:12:04 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 16:12:04 -0000 Subject: [GHC] #7669: Empty case causes warning In-Reply-To: <047.310ed8158a885c379e88cd726513d398@haskell.org> References: <047.310ed8158a885c379e88cd726513d398@haskell.org> Message-ID: <062.6d28bddea00523ef003a77896139b27d@haskell.org> #7669: Empty case causes warning -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: duplicate | Keywords: EmptyCase Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | deSugar/should_compile/T7669 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): The issue of no warnings being produced despite non-exhaustive pattern matches (described in comment:3) has been reported separately as #10746. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 16:46:28 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 16:46:28 -0000 Subject: [GHC] #9308: nofib fannkuch-redux runs perpetually with -fllvm In-Reply-To: <042.547b78253c22f834191c24f2af1b28cf@haskell.org> References: <042.547b78253c22f834191c24f2af1b28cf@haskell.org> Message-ID: <057.a193dbf820a6ed858bc9a4923f95db10@haskell.org> #9308: nofib fannkuch-redux runs perpetually with -fllvm -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.8.3 Resolution: | Keywords: fannkuch- | redux Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: fannkuch- at runtime | redux Blocked By: 9504 | Blocking: Related Tickets: #5567 | Differential Revisions: -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > Running the nofib benchmarks with make -k EXTRA_HC_OPTS=-fllvm on a HEAD > build of ghc configured with perf-llvm (3.4.2) results in fannkuch-redux > running in an infinite loop. The benchmark runs in about 3.5s without > the -fllvm > > {{{ > HC = /Users/xx/Projects/ghc/inplace/bin/ghc-stage2 > HC_OPTS = -O2 -Rghc-timing -H32m -hisuf hi -fllvm -rtsopts -XBangPatterns > -O2 > RUNTEST_OPTS = -ghc-timing > ==nofib== fannkuch-redux: time to compile Main follows... > /Users/jrp/Projects/ghc/inplace/bin/ghc-stage2 -O2 -Rghc-timing -H32m > -hisuf hi -fllvm -rtsopts -XBangPatterns -O2 -c Main.hs -o Main.o > < residency (6 samples), 57M in use, 0.00 INIT (0.00 elapsed), 0.20 MUT > (0.53 elapsed), 0.21 GC (0.23 elapsed) :ghc>> > ==nofib== fannkuch-redux: size of Main.o follows... > __TEXT __DATA __OBJC others dec hex > 10333 497 0 0 10830 2a4e > ==nofib== fannkuch-redux: time to link fannkuch-redux follows... > < samples), 25M in use, 0.00 INIT (0.00 elapsed), 0.01 MUT (0.53 elapsed), > 0.02 GC (0.02 elapsed) :ghc>> > ==nofib== fannkuch-redux: size of fannkuch-redux follows... > __TEXT __DATA __OBJC others dec hex > 4075520 446464 0 4295945496 4300467480 10053ed18 > ==nofib== fannkuch-redux: time to run fannkuch-redux follows... > ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout > -o1 fannkuch-redux.stdout -ghc-timing 11; > ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout > -o1 fannkuch-redux.stdout -ghc-timing 11; > ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout > -o1 fannkuch-redux.stdout -ghc-timing 11; > ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout > -o1 fannkuch-redux.stdout -ghc-timing 11; > ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout > -o1 fannkuch-redux.stdout -ghc-timing 11; > }}} New description: Running the nofib benchmarks with `make -k EXTRA_HC_OPTS=-fllvm` on a HEAD build of ghc configured with perf-llvm (3.4.2) results in fannkuch-redux running in an infinite loop. The benchmark runs in about 3.5s without the -fllvm {{{ HC = /Users/xx/Projects/ghc/inplace/bin/ghc-stage2 HC_OPTS = -O2 -Rghc-timing -H32m -hisuf hi -fllvm -rtsopts -XBangPatterns -O2 RUNTEST_OPTS = -ghc-timing ==nofib== fannkuch-redux: time to compile Main follows... /Users/jrp/Projects/ghc/inplace/bin/ghc-stage2 -O2 -Rghc-timing -H32m -hisuf hi -fllvm -rtsopts -XBangPatterns -O2 -c Main.hs -o Main.o <> ==nofib== fannkuch-redux: size of Main.o follows... __TEXT __DATA __OBJC others dec hex 10333 497 0 0 10830 2a4e ==nofib== fannkuch-redux: time to link fannkuch-redux follows... <> ==nofib== fannkuch-redux: size of fannkuch-redux follows... __TEXT __DATA __OBJC others dec hex 4075520 446464 0 4295945496 4300467480 10053ed18 ==nofib== fannkuch-redux: time to run fannkuch-redux follows... ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout -o1 fannkuch-redux.stdout -ghc-timing 11; ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout -o1 fannkuch-redux.stdout -ghc-timing 11; ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout -o1 fannkuch-redux.stdout -ghc-timing 11; ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout -o1 fannkuch-redux.stdout -ghc-timing 11; ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout -o1 fannkuch-redux.stdout -ghc-timing 11; }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 18:01:29 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 18:01:29 -0000 Subject: [GHC] #10600: -fwarn-incomplete-patterns doesn't work with -fno-code In-Reply-To: <043.972d3170891da80a4e96bca7b675a836@haskell.org> References: <043.972d3170891da80a4e96bca7b675a836@haskell.org> Message-ID: <058.420632a8337463d8ed9125ac2ff5512a@haskell.org> #10600: -fwarn-incomplete-patterns doesn't work with -fno-code -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8101 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Actually the fix in #8101 works in one-shot mode (`-c`), but not in make mode (the default). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 18:57:07 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 18:57:07 -0000 Subject: [GHC] #10600: -fwarn-incomplete-patterns doesn't work with -fno-code In-Reply-To: <043.972d3170891da80a4e96bca7b675a836@haskell.org> References: <043.972d3170891da80a4e96bca7b675a836@haskell.org> Message-ID: <058.49a3a3018bfb20a06b2ba99ae11fc3ae@haskell.org> #10600: -fwarn-incomplete-patterns doesn't work with -fno-code -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8101 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Reid Barton ): In [changeset:"aa230540f5868263740fd7d2f31505a39e2fcb4e/ghc" aa230540/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="aa230540f5868263740fd7d2f31505a39e2fcb4e" Add test for #10600 (exhaustiveness check with --make and -fno-code) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 18:57:35 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 18:57:35 -0000 Subject: [GHC] #10600: -fwarn-incomplete-patterns doesn't work with -fno-code In-Reply-To: <043.972d3170891da80a4e96bca7b675a836@haskell.org> References: <043.972d3170891da80a4e96bca7b675a836@haskell.org> Message-ID: <058.d44969935477680698df77b44d69b87b@haskell.org> #10600: -fwarn-incomplete-patterns doesn't work with -fno-code -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | driver/T8101b Blocked By: | Blocking: Related Tickets: #8101 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * testcase: => driver/T8101b -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 19:03:39 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 19:03:39 -0000 Subject: [GHC] #10744: Allow oneShot to work with unboxed types In-Reply-To: <043.1a18f79737236ccee17a4841dc4bdcd8@haskell.org> References: <043.1a18f79737236ccee17a4841dc4bdcd8@haskell.org> Message-ID: <058.f809d1819e670cc29628abf1cfef14b3@haskell.org> #10744: Allow oneShot to work with unboxed types -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Hmm, I am not sure if this is a valid use of `oneShot` if you cannot guarantee that the Builder will be used only once, as GHC and the runtime (probably) relies on the annotation to be correct, and you might get crashes at runtime. If everything is inlined enough the existing arity analyses might be able to eta-expand `serialize`, but that?s probably not reliably enough. But nevertheless, the feature request is of course valid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 20:30:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 20:30:48 -0000 Subject: [GHC] #7102: Type family instance overlap accepted in ghci In-Reply-To: <044.1bce8102b22a465aacd2599a3c22a7da@haskell.org> References: <044.1bce8102b22a465aacd2599a3c22a7da@haskell.org> Message-ID: <059.78c6c1adc6b0222ce8bc28f51ebbe3cf@haskell.org> #7102: Type family instance overlap accepted in ghci -------------------------------------+------------------------------------- Reporter: exbb2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by oerjan): I suspect the purging in (2) can already be achieved by just redeclaring the type family, after which new instances would refer to the new entity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 20:42:04 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 20:42:04 -0000 Subject: [GHC] #7919: Heap corruption (segfault) from large 'let' expression In-Reply-To: <045.3707d678a38441ef54b667e63e238d84@haskell.org> References: <045.3707d678a38441ef54b667e63e238d84@haskell.org> Message-ID: <060.bcc7d17f7cf47c896fcd97a7ecb5af03@haskell.org> #7919: Heap corruption (segfault) from large 'let' expression -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.12.1 Component: Runtime System | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: rts/T7919 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1113 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 21:14:54 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 21:14:54 -0000 Subject: [GHC] #10748: Associated type families regression Message-ID: <045.a31a39677d34cd413ba9729d236f893a@haskell.org> #10748: Associated type families regression -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The original code snippet is taken from synthesizer-core-0.7.1 from hackage: http://code.haskell.org/synthesizer/core/src/Synthesizer/Causal/Class.hs Here is the minimal example: {{{#!hs {-# LANGUAGE TypeFamilies #-} module M where class ProcessOf (SignalOf process) ~ process => C process where type SignalOf process :: * -> * type ProcessOf (signal :: * -> *) :: * -> * -> * }}} {{{ $ ghc -c M.hs M.hs:4:1: The associated type ?ProcessOf? mentions none of the type or kind variables of the class ?C process? In the class declaration for ?C? }}} ghc-7.8.4 was able to compile this. Is it a known new restriction of ghc or a regression? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 21:26:39 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 21:26:39 -0000 Subject: [GHC] #7102: Type family instance overlap accepted in ghci In-Reply-To: <044.1bce8102b22a465aacd2599a3c22a7da@haskell.org> References: <044.1bce8102b22a465aacd2599a3c22a7da@haskell.org> Message-ID: <059.a67228e160927f92aad0482f2a05bf46@haskell.org> #7102: Type family instance overlap accepted in ghci -------------------------------------+------------------------------------- Reporter: exbb2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by oerjan): Since you said not to mind Safe Haskell, I also found a similar unsoundness that uses loading of modules instead. All the modules can be `Safe`, but GHCi itself cannot have the flag set. {{{ {-# LANGUAGE Safe, TypeFamilies #-} module T1 where type family T a b }}} {{{ {-# LANGUAGE Safe, TypeFamilies #-} module T2 where import T1 type instance T a b = a from :: a -> T a b from = id }}} {{{ {-# LANGUAGE Safe, TypeFamilies #-} module T3 where import T1 type instance T a b = b to :: T a b -> b to = id }}} Now in GHCi: {{{ Prelude> :l T2 T3 [1 of 3] Compiling T1 ( T1.hs, interpreted ) [2 of 3] Compiling T3 ( T3.hs, interpreted ) [3 of 3] Compiling T2 ( T2.hs, interpreted ) Ok, modules loaded: T2, T1, T3. *T2> :m +T3 *T2 T3> let uc = to . from *T2 T3> uc 'a' :: Int 97 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 22:08:41 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 22:08:41 -0000 Subject: [GHC] #10744: Allow oneShot to work with unboxed types In-Reply-To: <043.1a18f79737236ccee17a4841dc4bdcd8@haskell.org> References: <043.1a18f79737236ccee17a4841dc4bdcd8@haskell.org> Message-ID: <058.482e9def8f70d5366e4ca3542c31908f@haskell.org> #10744: Allow oneShot to work with unboxed types -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by akio): Replying to [comment:4 nomeata]: > Hmm, I am not sure if this is a valid use of `oneShot` if you cannot guarantee that the Builder will be used only once, as GHC and the runtime (probably) relies on the annotation to be correct, and you might get crashes at runtime. Oh, I didn't know this, thank you for pointing it out. I had hoped that it worked the same way as the state hack, which does not cause a crash even if the assumption is violated and the IO action is used multiple times. If this is not a valid use of `oneShot`, I don't have real uses that involve unlifted types. I'm happy to close this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 22:17:12 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 22:17:12 -0000 Subject: [GHC] #10748: Associated type families regression In-Reply-To: <045.a31a39677d34cd413ba9729d236f893a@haskell.org> References: <045.a31a39677d34cd413ba9729d236f893a@haskell.org> Message-ID: <060.f4701dae8361203db00c07533236919e@haskell.org> #10748: Associated type families regression -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => invalid Comment: It is an intentional change. See #10300 for another example. `ProcessOf` has no direct relation to `C`, so it should be declared as a standalone type family, outside the class. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 22:49:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 22:49:06 -0000 Subject: [GHC] #10742: GHC cannot deduce (irrelevant) reflexive type equality. In-Reply-To: <043.70009c4283c94391a26903bd5c00c1e8@haskell.org> References: <043.70009c4283c94391a26903bd5c00c1e8@haskell.org> Message-ID: <058.c860b45aa2d7cc9dc9dcd0ed8f1b9620@haskell.org> #10742: GHC cannot deduce (irrelevant) reflexive type equality. -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Keywords: TypeLits Resolution: | GADTs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T10742 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ntc2): We worked around this problem in 7.10.2 so please go ahead and close the issue. I would close it myself, but I'm not sure which of "works in HEAD; please merge" and "close as fixed" to choose for the resolution reason. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 6 22:59:44 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Aug 2015 22:59:44 -0000 Subject: [GHC] #10742: GHC cannot deduce (irrelevant) reflexive type equality. In-Reply-To: <043.70009c4283c94391a26903bd5c00c1e8@haskell.org> References: <043.70009c4283c94391a26903bd5c00c1e8@haskell.org> Message-ID: <058.933538be042773309dd375e0a141f62f@haskell.org> #10742: GHC cannot deduce (irrelevant) reflexive type equality. -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Keywords: TypeLits Resolution: fixed | GADTs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T10742 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 04:50:52 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 04:50:52 -0000 Subject: [GHC] #10609: Make up instances In-Reply-To: <047.ffaf9fde9cde45ea3283521ce42e1f8c@haskell.org> References: <047.ffaf9fde9cde45ea3283521ce42e1f8c@haskell.org> Message-ID: <062.e83f9d955769d07cda8a288db22c09d6@haskell.org> #10609: Make up instances -------------------------------------+------------------------------------- Reporter: fumieval | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1049 -------------------------------------+------------------------------------- Comment (by bgamari): The `Traversable ZipList` instance was missing from the above commit and was added in a1c934c1b97a09db841d20da4811e0e1310f7511 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 05:38:39 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 05:38:39 -0000 Subject: [GHC] #10749: Boot file instances should imply superclasses Message-ID: <045.db4e226ba3e13bafad10871c24246b1d@haskell.org> #10749: Boot file instances should imply superclasses -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Currently, if I write the following program: {{{ -- A.hs-boot module A where data T instance Ord T -- B.hs module B where import {-# SOURCE #-} A f :: T -> T -> Bool f x y = x == y }}} I get: {{{ B.hs:4:11: No instance for (Eq T) arising from a use of `==' Possible fix: add an instance declaration for (Eq T) In the expression: x == y In an equation for `f': f x y = x == y }}} This is a bit confusing, because Ord instances are supposed to imply Eq instances. GHC should either: 1. Reject A.hs-boot (claiming that it could not find evidence that T had an Eq instance), or 2. Accept B.hs, since the instance requirement for Ord should imply Eq. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 06:24:29 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 06:24:29 -0000 Subject: [GHC] #7102: Type family instance overlap accepted in ghci In-Reply-To: <044.1bce8102b22a465aacd2599a3c22a7da@haskell.org> References: <044.1bce8102b22a465aacd2599a3c22a7da@haskell.org> Message-ID: <059.13932acd7cfef81865533e15433dbd6d@haskell.org> #7102: Type family instance overlap accepted in ghci -------------------------------------+------------------------------------- Reporter: exbb2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by oerjan): Oh hm, of course, purging that easily only works when the type family isn't imported from a module. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 06:45:35 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 06:45:35 -0000 Subject: [GHC] #10750: silly assembly for comparing Doubles Message-ID: <047.207ed991d667b8f8c95a3231e8362053@haskell.org> #10750: silly assembly for comparing Doubles -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #10137, #10677 Differential Revisions: | -------------------------------------+------------------------------------- A function like `f x = if x > 0.0 then ... else ...` compiles to the assembly {{{ movsd 7(%rbx),%xmm0 xorpd %xmm1,%xmm1 ucomisd %xmm1,%xmm0 seta %al movzbl %al,%eax cmpq $1,%rax jb _c1tb }}} This `seta/movzbl/cmpq/jb` is bad, we can just generate `ja` (and 7.10 did). The cause is that the code generator produces Cmm like {{{ switch [0 .. 1] %MO_F_Gt_W64(_s1sv::F64, 0.0 :: W64)::I64 { case 0 : goto c1tb; case 1 : goto c1tc; } }}} which turns into {{{ if (%MO_F_Gt_W64(_s1sv::F64, 0.0 :: W64) < 1) goto c1tb; else goto c1tc; }}} and then GHC is stuck. It knows how to turn `condition >= 1` into `condition`, and it knows how to turn `condition < 1` into a negated version of `condition` when possible, but there is no negated version of `MO_F_Gt_W64` (it's not `MO_F_Le_W64` because of NaNs and signed zeros). It doesn't know how to turn a negated conditional into a conditional with the branches swapped because it doesn't look at that much at once. Presumably more fallout from #10137, and maybe can be fixed simultaneously with #10677. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 06:53:20 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 06:53:20 -0000 Subject: [GHC] #10677: slightly silly assembly for testing whether a Word# is 0## In-Reply-To: <047.666ef36ac1cc91ac56611c092c7fbb22@haskell.org> References: <047.666ef36ac1cc91ac56611c092c7fbb22@haskell.org> Message-ID: <062.59957f774de2c70250c82a45146229dc@haskell.org> #10677: slightly silly assembly for testing whether a Word# is 0## -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10750 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * related: => #10750 Comment: See also #10750 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 07:16:33 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 07:16:33 -0000 Subject: [GHC] #10751: Implement Phase 1 of MonadFail Proposal (MFP) Message-ID: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> #10751: Implement Phase 1 of MonadFail Proposal (MFP) -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.2 Keywords: report- | Operating System: Unknown/Multiple impact | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- See also - https://www.reddit.com/r/haskell/comments/3a1o06/monadfail_proposal_mfp/ TODO: At this point this ticket is mostly a reminder that stuff may need to be done for GHC 7.12 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 07:17:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 07:17:01 -0000 Subject: [GHC] #10744: Allow oneShot to work with unboxed types In-Reply-To: <043.1a18f79737236ccee17a4841dc4bdcd8@haskell.org> References: <043.1a18f79737236ccee17a4841dc4bdcd8@haskell.org> Message-ID: <058.7c6c72c026180b3c4d3cba367ab4df02@haskell.org> #10744: Allow oneShot to work with unboxed types -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Wait wait! I?m just saying that at the moment, I cannot guarantee that it is safe. It is possible that it is safe after all (and I really need to investigate and document that). And if not, it might be possible to make it safe, now that we have a real use case! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 07:53:59 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 07:53:59 -0000 Subject: [GHC] #10744: Allow oneShot to work with unboxed types In-Reply-To: <043.1a18f79737236ccee17a4841dc4bdcd8@haskell.org> References: <043.1a18f79737236ccee17a4841dc4bdcd8@haskell.org> Message-ID: <058.10333d03ca61072126c538e3d4998c12@haskell.org> #10744: Allow oneShot to work with unboxed types -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by akio): Ah sorry, I had misinterpreted your comment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 08:08:53 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 08:08:53 -0000 Subject: [GHC] #10744: Allow oneShot to work with unboxed types In-Reply-To: <043.1a18f79737236ccee17a4841dc4bdcd8@haskell.org> References: <043.1a18f79737236ccee17a4841dc4bdcd8@haskell.org> Message-ID: <058.415ca59d56e8651f075e9328e938fb26@haskell.org> #10744: Allow oneShot to work with unboxed types -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I think it'd be fine to allow `oneShot` to accept unboxed types; just a matter of using `openAlphaTyVar` etc in `MkId.oneShot`. Give it a try and submit a patch. Moreover, the worst that can happen if you mis-use it, by applying it to a function that is called many times, is that computation may be repeated. For example {{{ f xs y = let x = expensive_fn y in map (oneShot (\v. x+v)) xs }}} The `oneShot` claims (falsely unless `xs` has length at most one) that `(\v. x+v)` is called at most once. So GHC will move the call to `expensive_fn` inside the lambda thus: {{{ f xs y = map (oneShot (\v. expensive_fn y + v)) xs }}} That will work just fine, but it'll call `expensive_fn` once per element of `xs`. So, no seg-faults at least! It would be good if someone felt like extending the Haddock comments for `GHC.Magic.oneShot` to explain this. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 08:10:34 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 08:10:34 -0000 Subject: [GHC] #10744: Allow oneShot to work with unboxed types In-Reply-To: <043.1a18f79737236ccee17a4841dc4bdcd8@haskell.org> References: <043.1a18f79737236ccee17a4841dc4bdcd8@haskell.org> Message-ID: <058.1068bfa20861fda011ef6f1daa471c3c@haskell.org> #10744: Allow oneShot to work with unboxed types -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Simon, I am worried that due to a wrong annotation here, a thunk is marked as single entry that is not really single entry, and I can imagine that bad things can happen then. But if you think that this cannot happen, then I?d be relieved, and akio can go forwared using `oneShot`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 08:11:55 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 08:11:55 -0000 Subject: [GHC] #10748: Associated type families regression In-Reply-To: <045.a31a39677d34cd413ba9729d236f893a@haskell.org> References: <045.a31a39677d34cd413ba9729d236f893a@haskell.org> Message-ID: <060.516d90b9f50ea3c33f405c78111ff42f@haskell.org> #10748: Associated type families regression -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by slyfox): Aha, I see. Ported as: {{{#!diff diff --git a/src/Synthesizer/Causal/Class.hs b/src/Synthesizer/Causal/Class.hs index 358dd85..89c9c71 100644 --- a/src/Synthesizer/Causal/Class.hs +++ b/src/Synthesizer/Causal/Class.hs @@ -12,7 +12,8 @@ import Control.Arrow (Arrow, arr, (<<<), (&&&), ) +type family ProcessOf (signal :: * -> *) :: * -> * -> * + class (Arrow process, ProcessOf (SignalOf process) ~ process) => C process where type SignalOf process :: * -> * - type ProcessOf (signal :: * -> *) :: * -> * -> * toSignal :: process () a -> SignalOf process a fromSignal :: SignalOf process b -> process a b diff --git a/src/Synthesizer/Causal/Process.hs b/src/Synthesizer/Causal/Process.hs index e64afcd..33027ef 100644 --- a/src/Synthesizer/Causal/Process.hs +++ b/src/Synthesizer/Causal/Process.hs @@ -175,8 +175,8 @@ instance ArrowLoop T where loop = liftKleisli loop +type instance Class.ProcessOf Sig.T = T instance Class.C T where type SignalOf T = Sig.T - type ProcessOf Sig.T = T toSignal = flip applyConst () fromSignal sig = const () ^>> feed sig }}} Thank you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 08:22:33 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 08:22:33 -0000 Subject: [GHC] #10744: Allow oneShot to work with unboxed types In-Reply-To: <043.1a18f79737236ccee17a4841dc4bdcd8@haskell.org> References: <043.1a18f79737236ccee17a4841dc4bdcd8@haskell.org> Message-ID: <058.dc6e23438fc378755e4995335d38a3b6@haskell.org> #10744: Allow oneShot to work with unboxed types -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Replying to [comment:9 nomeata]: > Simon, I am worried that due to a wrong annotation here, a thunk is marked as single entry that is not really single entry, and I can imagine that bad things can happen then. But if you think that this cannot happen, then I?d be relieved, and akio can go forwared using `oneShot`. Yes, this is what happened in #10414 and #10218. Suppose in my example in comment:8 that GHC does ''not'' float the `let x` thunk into the lambda for some reason. Then it might instead be marked single-entry. So we get {{{ f xs y = let x[single-entry] = expensive_fn y in map (oneShot (\v. x+v)) xs }}} The bad thing in #10414 and #10218 was that, with eager black-holing, `x` was blackholed, so that the second time it was entered we got `<>`. But the fix in ticket:10414#comment:29 switches off eager-blackholing for single-entry thunks, so it'll all be fine. So, because of that, I think we are good. Mind you, if we implement the sanity check in #10613, you might get failures reported due to bogus `oneShot` claims. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 08:26:39 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 08:26:39 -0000 Subject: [GHC] #10752: Print which warning-flag controls/enabled an emitted warning Message-ID: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> #10752: Print which warning-flag controls/enabled an emitted warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Both `gcc` and `clang` tell which warning flag a reported warning can be controlled with, e.g. {{{ $ clang-3.5 -Wall -c hello.c hello.c:3:7: warning: unused variable 'x' [-Wunused-variable] int x; ^ 1 warning generated. }}} {{{ $ gcc -Wall -c hello.c hello.c: In function ?main?: hello.c:3:7: warning: unused variable ?x? [-Wunused-variable] int x; ^ hello.c:4:1: warning: control reaches end of non-void function [-Wreturn- type] } ^ }}} With GHC however, we need to lookup the documentation (or memorise all warning flags) to find out which `-fno-warn-*` flag we need to use to silence a specific warning. I propose we augment GHC's warnings in a similar style to how `gcc`/`clang` report flags in compile warnings. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 08:27:57 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 08:27:57 -0000 Subject: [GHC] #10744: Allow oneShot to work with unboxed types In-Reply-To: <043.1a18f79737236ccee17a4841dc4bdcd8@haskell.org> References: <043.1a18f79737236ccee17a4841dc4bdcd8@haskell.org> Message-ID: <058.b2b2c0f1562a272ed5815b46573b77e5@haskell.org> #10744: Allow oneShot to work with unboxed types -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Interestingly, I cannot even make GHC mark such a thunk as a `\s` closure in the STG output (which is what we are looking for, right?). Anyways, I?ll prepare a patch to make `oneShot` open-kinded, and also update the docs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 08:36:22 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 08:36:22 -0000 Subject: [GHC] #7102: Type family instance overlap accepted in ghci In-Reply-To: <044.1bce8102b22a465aacd2599a3c22a7da@haskell.org> References: <044.1bce8102b22a465aacd2599a3c22a7da@haskell.org> Message-ID: <059.0d4e5530c2c01bef79c6dc71d0fb0359@haskell.org> #7102: Type family instance overlap accepted in ghci -------------------------------------+------------------------------------- Reporter: exbb2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Eek. Of course GHCi should do an eager instance-overlap check when loading modules, just as GHC does. That is a serious bug. Again, nothign to do with Safe Haskell; your example works just as well without `{-# LANGUAGE Safe #-}`. Would anyone like to look at it? The code is all there, since it is used for dealing with imports in GHC. > I suspect the purging in (2) can already be achieved by just redeclaring the type family, after which new instances would refer to the new entity. Ah yes, that is true. Clever. So this is what would happen {{{ Prelude> type family T a b Prelude> type instance T a b = a Prelude> let uc :: a -> T a b; uc = id Prelude> type instance T a b = b ERROR: instance overlap -- User thinks: darn! Re-declare T Prelude> type family T a b -- This is a brand-new T, unrelated to the old one Prelude> uc 'a' :: Int :6:1: error: Couldn't match type ?Char? with ?Int? Expected type: Int Actual type: Ghci1.T Char b0 }}} So, no need to add a new facility for purging. What we need is to reject overlap. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 08:36:53 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 08:36:53 -0000 Subject: [GHC] #10744: Allow oneShot to work with unboxed types In-Reply-To: <043.1a18f79737236ccee17a4841dc4bdcd8@haskell.org> References: <043.1a18f79737236ccee17a4841dc4bdcd8@haskell.org> Message-ID: <058.96e57bdd07a32d7addee0a810fa57a0a@haskell.org> #10744: Allow oneShot to work with unboxed types -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1136 -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => patch * differential: => Phab:D1136 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 08:39:25 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 08:39:25 -0000 Subject: [GHC] #10677: slightly silly assembly for testing whether a Word# is 0## In-Reply-To: <047.666ef36ac1cc91ac56611c092c7fbb22@haskell.org> References: <047.666ef36ac1cc91ac56611c092c7fbb22@haskell.org> Message-ID: <062.304d8fb43907e424addef927151c59ef@haskell.org> #10677: slightly silly assembly for testing whether a Word# is 0## -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10750 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Is there a good way to have test cases for these issues? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 08:54:34 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 08:54:34 -0000 Subject: [GHC] #10750: silly assembly for comparing Doubles In-Reply-To: <047.207ed991d667b8f8c95a3231e8362053@haskell.org> References: <047.207ed991d667b8f8c95a3231e8362053@haskell.org> Message-ID: <062.21b52a0678e49bd9c15582539d50d67f@haskell.org> #10750: silly assembly for comparing Doubles -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10137, #10677 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Can you provide me with a working example? For some reason, if I try to reproduce it, I get code that actually calls `GHC.Classes.>_info`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 08:54:38 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 08:54:38 -0000 Subject: [GHC] #10677: slightly silly assembly for testing whether a Word# is 0## In-Reply-To: <047.666ef36ac1cc91ac56611c092c7fbb22@haskell.org> References: <047.666ef36ac1cc91ac56611c092c7fbb22@haskell.org> Message-ID: <062.b4b33101752470ae336565c9028b2d8b@haskell.org> #10677: slightly silly assembly for testing whether a Word# is 0## -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10750 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): I tried to fix this, but now (presumably due to a later optimization) it produces {{{ testq %r14,%r14 jne _cQl }}} I hope that is ok as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 08:57:02 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 08:57:02 -0000 Subject: [GHC] #10677: slightly silly assembly for testing whether a Word# is 0## In-Reply-To: <047.666ef36ac1cc91ac56611c092c7fbb22@haskell.org> References: <047.666ef36ac1cc91ac56611c092c7fbb22@haskell.org> Message-ID: <062.f84b90ed1646c5c99f7d67ba96c2be46@haskell.org> #10677: slightly silly assembly for testing whether a Word# is 0## -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10750 | Differential Revisions: Phab:D1137 -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => patch * differential: => Phab:D1137 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 09:15:04 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 09:15:04 -0000 Subject: [GHC] #10750: silly assembly for comparing Doubles In-Reply-To: <047.207ed991d667b8f8c95a3231e8362053@haskell.org> References: <047.207ed991d667b8f8c95a3231e8362053@haskell.org> Message-ID: <062.85a8d7c705ca8022e5e33dbef2fd8afa@haskell.org> #10750: silly assembly for comparing Doubles -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10137, #10677 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Anyways, with #10677 resp. D1137, the conditions should be `condition != 0`, which will hopefully be turned into `condition`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 10:53:40 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 10:53:40 -0000 Subject: [GHC] #10753: Type checker fails to recognize equality Message-ID: <043.7210f23800707e120b21490cf6110634@haskell.org> #10753: Type checker fails to recognize equality -------------------------------------+------------------------------------- Reporter: ljli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE KindSignatures #-} module Test where import qualified Control.Monad.State as S class HasConns (m :: * -> *) where type Conn m foo :: (HasConns m, Monad m) => S.StateT (Conn m) m () foo = do _ <- S.get return () }}} This fails to compile with GHC 7.10.2: {{{ Could not deduce (S.MonadState (Conn m) (S.StateT (Conn m) m)) arising from a use of ?S.get? from the context (HasConns m, Monad m) bound by the type signature for foo :: (HasConns m, Monad m) => S.StateT (Conn m) m () }}} It compiles with GHC 7.8.4, though. Adding "Conn m ~ Conn m" to the type context of foo lets it compile again. This seems not right to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 11:18:37 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 11:18:37 -0000 Subject: [GHC] #10753: Type checker fails to recognize equality In-Reply-To: <043.7210f23800707e120b21490cf6110634@haskell.org> References: <043.7210f23800707e120b21490cf6110634@haskell.org> Message-ID: <058.5c367f224c09966a3116c7fdc7e27077@haskell.org> #10753: Type checker fails to recognize equality -------------------------------------+------------------------------------- Reporter: ljli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Yes this is a bug, actually a dup of #10340. Sadly the fix was not straightforward and won't end up in 7.10. I hope you can work around it meanwhile. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 11:19:51 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 11:19:51 -0000 Subject: [GHC] #10340: Type inference regression with Any In-Reply-To: <043.6973fe6949fc7fde77cc0902c496af6e@haskell.org> References: <043.6973fe6949fc7fde77cc0902c496af6e@haskell.org> Message-ID: <058.85195d1959c6842b3fb0fa5a18f91bdc@haskell.org> #10340: Type inference regression with Any -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T10340 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => indexed-types/should_compile/T10340 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 11:32:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 11:32:05 -0000 Subject: [GHC] #10753: Type checker fails to recognize equality In-Reply-To: <043.7210f23800707e120b21490cf6110634@haskell.org> References: <043.7210f23800707e120b21490cf6110634@haskell.org> Message-ID: <058.8c618e12f063e4d2bedab6aa395635d0@haskell.org> #10753: Type checker fails to recognize equality -------------------------------------+------------------------------------- Reporter: ljli | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T10753 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => indexed-types/should_compile/T10753 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 11:32:25 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 11:32:25 -0000 Subject: [GHC] #10487: DeriveGeneric breaks when the same data name is used in different modules In-Reply-To: <051.f823b016355f38c348182e98da9d4ae1@haskell.org> References: <051.f823b016355f38c348182e98da9d4ae1@haskell.org> Message-ID: <066.99584e97c3eec1ed1cedf9a4ac6973ac@haskell.org> #10487: DeriveGeneric breaks when the same data name is used in different modules -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1081 -------------------------------------+------------------------------------- Comment (by osa1): Simon asked for a concrete example and some explanations on Phabricator thread so here it is: (I'm just learning this stuff so there may be mistakes) When we ask GHC to derive a Generic instance, it generates some instances other than Generic, and it also generates new data types for constructors of the type(and I think also for fields of constructors). Let's say I have this: {{{ module N where import GHC.Generics data Name = N1 String | N2 Int deriving instance Generic Name }}} GHC generates these instances: {{{ instance GHC.Generics.Generic N.Name where GHC.Generics.from (N.N1 g1_a17z) = ... GHC.Generics.from (N.N2 g1_a17A) = ... GHC.Generics.to (...) = ... GHC.Generics.to (...) = ... instance GHC.Generics.Datatype N.D1Name where GHC.Generics.datatypeName _ = "Name" GHC.Generics.moduleName _ = "N" instance GHC.Generics.Constructor N.C1_0Name where GHC.Generics.conName _ = "N1" instance GHC.Generics.Constructor N.C1_1Name where GHC.Generics.conName _ = "N2" }}} and these new data types: {{{ N.D1Name N.C1_0Name N.C1_1Name N.S1_0_0Name N.S1_1_0Name }}} Now the problem is, if I have something like this: {{{ module N where import GHC.Generics import qualified M as Blah data Name = Name deriving instance Generic Blah.Name deriving instance Generic Name --- module M where data Name = Name }}} It generates same data types and instances(including head parts, because generated data types are same so instance heads have to refer to same names) for both Names. This leads to duplicate data type and instance declarations. What I did for D1081 so far was to add module names as prefix to generated data types. It worked fine(currently validates), but if we use package imports it should break. So we thought maybe we should use qualified names of modules as a prefix. In our case, that would mean generating `Blah_` prefixed types for `Name` in module `M`, and non-prefixed types for `Name` in current module. With package imports the user need to give modules different names so this should work. But it turns out to be hard to implement, because at the point we're generating instance code, we don't have any knowledge about qualified imports. `RdrName`s are eliminated during renaming. With some experiments I realized `Outputable.PrintUnqualified` doesn't give this info etc. That's where I got stuck. We thought of some solutions: - Add `RdrName` as a field to `Name`. `Name` is a pretty central data type and we may not want to change it. Also, this probably means changing a lot of other code. - Pass `RdrName`s through type checker. No changes in any data types, but we still need to change a lot of other code, functions etc. just to pass this argument through. - (We had the idea of using `Outputable.PrintUnqualified` data but that won't work) I must mention, I don't have an example with package imports. Maybe GHC is already giving modules different names when package imports is used? That would solve everything. I'll try to build a broken(with my patch) example today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 11:32:52 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 11:32:52 -0000 Subject: [GHC] #10753: Type checker fails to recognize equality In-Reply-To: <043.7210f23800707e120b21490cf6110634@haskell.org> References: <043.7210f23800707e120b21490cf6110634@haskell.org> Message-ID: <058.952bb3dd4000feabb1bc8cd86ba7d092@haskell.org> #10753: Type checker fails to recognize equality -------------------------------------+------------------------------------- Reporter: ljli | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T10753 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"79e0a10e541724713f1149c468ba966b7fc819d3/ghc" 79e0a10e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="79e0a10e541724713f1149c468ba966b7fc819d3" Test Trac #10753 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 11:41:34 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 11:41:34 -0000 Subject: [GHC] #10487: DeriveGeneric breaks when the same data name is used in different modules In-Reply-To: <051.f823b016355f38c348182e98da9d4ae1@haskell.org> References: <051.f823b016355f38c348182e98da9d4ae1@haskell.org> Message-ID: <066.d565d791590f5ad940d5177136191e97@haskell.org> #10487: DeriveGeneric breaks when the same data name is used in different modules -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1081 -------------------------------------+------------------------------------- Comment (by simonpj): Are the newly declared data types supposed to be user-visible, with predictable names (they don't look very user-friendly!) or is it just an internal matter. If it's just a question of generating fresh names that are distinct, you could use the same approach as for dictionary-functions. Look at `TcEnv.newDFunName`. This reminds me (Andres) that there is an outstanding task to clean up this generics stuff using `DataKinds`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 11:56:50 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 11:56:50 -0000 Subject: [GHC] #10487: DeriveGeneric breaks when the same data name is used in different modules In-Reply-To: <051.f823b016355f38c348182e98da9d4ae1@haskell.org> References: <051.f823b016355f38c348182e98da9d4ae1@haskell.org> Message-ID: <066.cd17f95d2d7596ecc7871b6eade5716b@haskell.org> #10487: DeriveGeneric breaks when the same data name is used in different modules -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1081 -------------------------------------+------------------------------------- Comment (by osa1): I don't think they're user visible, because for example if I load the file in GHCi I can't see those types there(although I must say I don't know how this is possible to implement, I'd expect everything in that module to be visible). I'll have a look at `TcEnv.newDFunName`, it sounds like a great idea. Is there a ticket for the clean up task? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 12:00:04 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 12:00:04 -0000 Subject: [GHC] #10487: DeriveGeneric breaks when the same data name is used in different modules In-Reply-To: <051.f823b016355f38c348182e98da9d4ae1@haskell.org> References: <051.f823b016355f38c348182e98da9d4ae1@haskell.org> Message-ID: <066.ceede0d3be8ac61fdc923fa2a6047e84@haskell.org> #10487: DeriveGeneric breaks when the same data name is used in different modules -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1081 -------------------------------------+------------------------------------- Comment (by simonpj): > Is there a ticket for the clean up task? I don't think so -- there should be -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 12:53:24 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 12:53:24 -0000 Subject: [GHC] #9447: Add support for resizing `MutableByteArray#`s In-Reply-To: <042.51867a8225b599fb4ff13dcceb122580@haskell.org> References: <042.51867a8225b599fb4ff13dcceb122580@haskell.org> Message-ID: <057.3d999ad9fdca86e2634a43968ac22128@haskell.org> #9447: Add support for resizing `MutableByteArray#`s -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D133 -------------------------------------+------------------------------------- Comment (by bgamari): See Phab:D1139 for an implementation of `getSizeofMutableByteArray#`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 12:53:44 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 12:53:44 -0000 Subject: [GHC] #9447: Add support for resizing `MutableByteArray#`s In-Reply-To: <042.51867a8225b599fb4ff13dcceb122580@haskell.org> References: <042.51867a8225b599fb4ff13dcceb122580@haskell.org> Message-ID: <057.2c9b4d8c4adde3c0fa1770c3f33c5232@haskell.org> #9447: Add support for resizing `MutableByteArray#`s -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D133, | Phab:D1139 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: Phab:D133 => Phab:D133, Phab:D1139 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 13:07:38 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 13:07:38 -0000 Subject: [GHC] #5296: Add explicit type applications In-Reply-To: <042.d7f5be0512efad8881e5f10e7830add1@haskell.org> References: <042.d7f5be0512efad8881e5f10e7830add1@haskell.org> Message-ID: <057.2960048567bae060d00c2da01c2c32b7@haskell.org> #5296: Add explicit type applications -------------------------------------+------------------------------------- Reporter: dsf | Owner: goldfire Type: feature request | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.0.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 1897 | Blocking: Related Tickets: | Differential Revisions: Phab:D1138 -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire * differential: => Phab:D1138 * os: Linux => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple Comment: Patch available now, at Phab:D1138 and at branch `wip/type-app`. There are implementation notes in Phab. Here are some design notes: * There is no explicit ''kind'' instantiation. It just won't parse! This will be fixed along with Phab:D808. * The new extension `TypeApplications` implies `AllowAmbiguousTypes`. This makes sense, because in the presence of visible type application, there is really no such thing as an ambiguous type. * Suppose there is no `Eq` instance for `T` and `a,b :: T`. The expression `a == b` is clearly ill-typed. Previously, the error was reported on the `==`. Now it's reported on the whole expression. I think this makes sense. I have two open design questions: 1. What to do with `:type` in GHCi? Suppose we have `pair :: forall a. a -> forall b. b -> (a,b)`. I ask `:type pair 3`. The real type of this expression is `forall b. b -> (a0, b)`, where `a0` is the type of the overloaded `3`. The problem is that this type loses the fact that we need `Num a0`. We could say `forall b. Num a0 => b -> (a0, b)`, which is a little closer. Would we report that without `-fprint-explicit-foralls`? It would be wrong to say `forall a b. Num a => b -> (a, b)` (as is done today, even with this patch) because we can't instantiate `a` with a further visible type application. 2. It would be nice to be able to say `3 @Int` instead of `(3 :: Int)`. But this doesn't work out. Writing `3` in code really means `fromInteger $3` (where `$3` is the internal representation for the `Integer` 3). `fromInteger` comes from the `Num` class; it has type `forall a. Num a => Integer -> a`. So, we would want `3 @Int` to really become `fromInteger @Int $3`. But this is hard to arrange for. Alternatively, we could change `fromInteger` to have type `Integer -> forall a. Num a => a`, which would work swimmingly. But we can't do this, because class methods always have their class variables quantified first. Making this change would mean writing a wrapper around `fromInteger`: {{{ fromIntegerVta :: Integer -> forall a. Num a => a fromIntegerVta = fromInteger }}} Interpreting overloaded numbers in Haskell source would then use `fromIntegerVta`. But this is all a little painful. Is it worth it to have `3 @Int`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 13:08:37 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 13:08:37 -0000 Subject: [GHC] #10754: truncate /= double2Int Message-ID: <043.90ddeb54230f66037ee120962cf0eb95@haskell.org> #10754: truncate /= double2Int -------------------------------------+------------------------------------- Reporter: cblp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.2 libraries/base | Keywords: truncate, | Operating System: Unknown/Multiple double2Int, rewrite, rule | Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- There is a rule in libraries/base/GHC/Float.hs: {{{#!hs "truncate/Double->Int" truncate = double2Int }}} But it is not true for some values. Particularly, {{{#!hs let infinity = 1/0 :: Double truncate infinity :: Int == 0 double2Int infinity == -9223372036854775808 -- minBound }}} As a result, the value of {{{truncate (1/0 :: Double) :: Int}}} depends on optimization level. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 14:10:06 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 14:10:06 -0000 Subject: [GHC] #10067: The Read Integer instance is too slow In-Reply-To: <045.2129a6dab0c443575ce604d52432a575@haskell.org> References: <045.2129a6dab0c443575ce604d52432a575@haskell.org> Message-ID: <060.06c6d19cb014de02144dc15fffad8791@haskell.org> #10067: The Read Integer instance is too slow -------------------------------------+------------------------------------- Reporter: redneb | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D645 -------------------------------------+------------------------------------- Changes (by bgamari): * priority: high => normal * status: new => closed * resolution: => fixed Comment: As far as I can tell the critical issue of quadratic parsing of integers is by Phab:D645, which has been merged. The only work that remains here is to specialize for `Natural` but as Edward points out this is now a reasonable cheap operation as we can show, {{{#!hs import GHC.Natural import Criterion.Main main = defaultMain [ bench "integer" $ nf (read :: String -> Integer) (take 1000000 $ cycle "1234567890") , bench "natural" $ nf (read :: String -> Natural) (take 1000000 $ cycle "1234567890") ] }}} {{{ $ ghc Test.hs -O -fforce-recomp [1 of 1] Compiling Main ( Test.hs, Test.o ) Linking Test ... $ ./Test benchmarking integer time 435.5 ms (410.6 ms .. 484.4 ms) 0.998 R? (0.997 R? .. 1.000 R?) mean 441.3 ms (434.3 ms .. 445.5 ms) std dev 6.383 ms (0.0 s .. 7.230 ms) variance introduced by outliers: 19% (moderately inflated) benchmarking natural time 428.2 ms (415.5 ms .. 446.6 ms) 1.000 R? (1.000 R? .. 1.000 R?) mean 434.6 ms (432.0 ms .. 436.0 ms) std dev 2.261 ms (0.0 s .. 2.387 ms) variance introduced by outliers: 19% (moderately inflated) }}} For this reason I"m going to close this issue.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 15:01:17 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 15:01:17 -0000 Subject: [GHC] #10749: Boot file instances should imply superclasses In-Reply-To: <045.db4e226ba3e13bafad10871c24246b1d@haskell.org> References: <045.db4e226ba3e13bafad10871c24246b1d@haskell.org> Message-ID: <060.70188d6dfde72da8d736c4400ae6b861@haskell.org> #10749: Boot file instances should imply superclasses -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): I vote for (1). A.hs-boot is wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 15:20:34 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 15:20:34 -0000 Subject: [GHC] #10067: The Read Integer instance is too slow In-Reply-To: <045.2129a6dab0c443575ce604d52432a575@haskell.org> References: <045.2129a6dab0c443575ce604d52432a575@haskell.org> Message-ID: <060.1b7a644eb9810105a24d6dd99e4908cc@haskell.org> #10067: The Read Integer instance is too slow -------------------------------------+------------------------------------- Reporter: redneb | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D645 -------------------------------------+------------------------------------- Comment (by redneb): Yes, as I mentioned above, the `Read` instance of `Natural` relies on the `Read` instance of `Integer` so we get a speed-up for `Natural` as well. Unfortunately, this is not the case for the lexers from `Text.Read.Lex`, namely `readIntP`, `readOctP`, `readDecP`, `readHexP`: they only use the new algorithm for `Integer` but not for `Natural`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 15:37:38 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 15:37:38 -0000 Subject: [GHC] #10755: Add `MonadPlus IO` and `Alternative IO` instances Message-ID: <042.9475d11a3f91fa4e741f69ce0a266155@haskell.org> #10755: Add `MonadPlus IO` and `Alternative IO` instances -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Core | Version: Libraries | Keywords: report- | Operating System: Unknown/Multiple impact | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Cloned and adapted from #9588: ---- The following 2 instances are currently Orphans in `transformers` but shall be defined in `base` instead: {{{#!hs instance MonadPlus IO instance Alternative IO }}} This proposal by SPJ already passed the CLC back in April and only needs implementing. I'll submit a patch shortly to Phab ---- This needs coordination w/ Ross as `transformers` must not define the same instances for new enough `base` versions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 15:38:18 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 15:38:18 -0000 Subject: [GHC] #5296: Add explicit type applications In-Reply-To: <042.d7f5be0512efad8881e5f10e7830add1@haskell.org> References: <042.d7f5be0512efad8881e5f10e7830add1@haskell.org> Message-ID: <057.3be5e1db071b39ba944e4e88f313895e@haskell.org> #5296: Add explicit type applications -------------------------------------+------------------------------------- Reporter: dsf | Owner: goldfire Type: feature request | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.0.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 1897 | Blocking: Related Tickets: | Differential Revisions: Phab:D1138 -------------------------------------+------------------------------------- Comment (by simonpj): Can I tell, in GHCi, whether a particular function (perhaps in scope by being imported) is amenably to VTA? Perhaps `:info f` tells me? For (2) I suggest just saying `(3 :: Int)`. There are more exciting things to do than allow "@" in place of "::". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 15:39:16 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 15:39:16 -0000 Subject: [GHC] #9588: Add `MonadPlus (Either e)` and `Alternative (Either e)` instances (was: Add `MonadPlus {IO, Either e}` and `Alternative (Either e)` instances) In-Reply-To: <042.81b9305fea59cb0eb6b8168a5d80498d@haskell.org> References: <042.81b9305fea59cb0eb6b8168a5d80498d@haskell.org> Message-ID: <057.801535c5f5c91c2d9b305809319aeed3@haskell.org> #9588: Add `MonadPlus (Either e)` and `Alternative (Either e)` instances -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: ? Component: Core Libraries | Version: Resolution: | Keywords: report- | impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10755 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * related: => #10755 * milestone: 7.12.1 => ? Old description: > The following 3 instances are currently Orphans in `transformers` but > shall be defined in `base` instead: > > {{{#!hs > instance MonadPlus IO > instance MonadPlus (Either e) > instance Alterantive (Either e) > }}} > > This proposal by SPJ already passed the CLC back in April and only needs > implementing. I'll submit a patch shortly to Phab New description: The following 2 instances are currently Orphans in `transformers` but shall be defined in `base` instead: {{{#!hs instance MonadPlus (Either e) instance Alterantive (Either e) }}} This proposal by SPJ already passed the CLC back in April and only needs implementing. I'll submit a patch shortly to Phab -- Comment: I've split off the easy doable part into #10755 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 15:42:34 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 15:42:34 -0000 Subject: [GHC] #5296: Add explicit type applications In-Reply-To: <042.d7f5be0512efad8881e5f10e7830add1@haskell.org> References: <042.d7f5be0512efad8881e5f10e7830add1@haskell.org> Message-ID: <057.09b1d330b712f706a47daead84ff4d00@haskell.org> #5296: Add explicit type applications -------------------------------------+------------------------------------- Reporter: dsf | Owner: goldfire Type: feature request | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.0.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 1897 | Blocking: Related Tickets: | Differential Revisions: Phab:D1138 -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:18 simonpj]: > Can I tell, in GHCi, whether a particular function (perhaps in scope by being imported) is amenably to VTA? Perhaps `:info f` tells me? No. But there should be. `:info` would be easy to modify. But I think `:type` should indicate this as well somehow. > > For (2) I suggest just saying `(3 :: Int)`. There are more exciting things to do than allow "@" in place of "::". Yes, I suppose that's true. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 15:56:36 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 15:56:36 -0000 Subject: [GHC] #10756: Allow users to indicate inaccessible patterns Message-ID: <044.44fc866587983798150a57353bc7bdbd@haskell.org> #10756: Allow users to indicate inaccessible patterns -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Consider {{{#!hs {-# LANGUAGE KindSignatures #-} {-# LANGUAGE GADTs #-} data Elem :: * -> * -> * where EZ :: Elem (f , fs) f ES :: Elem fs f -> Elem (f', fs) f elemAbsurd :: Elem () f -> a elemAbsurd _ = error "inaccessible" }}} This catch-all in `elemAbsurd` is very unfortunate, because if I change my datatype and not all cases are inaccessible anymore the type checker will not be warning me. Although of course there is recent work by SPJ et al on inferring more inaccessible cases, I think it would be tremendously useful for users to be able to indicate that patterns are in fact inaccesible. I'd be very happy if I could write {{{#!hs elemAbsurd :: Elem () f -> a elemAbsurd EZ = inaccessible elemAbsurd (ES _) = inaccessible }}} Note that ghc ''can already detect that these patterns are in fact inaccessible'': it won't let me write the above: {{{ T.hs:12:12: Couldn't match type ?()? with ?(f, fs)? Inaccessible code in a pattern with constructor EZ :: forall f fs. Elem (f, fs) f, in an equation for ?elemAbsurd? }}} So I think it should be very very simple to change the type checker to allow to write cases like this if and only if the RHS is a specially designated symbol "inaccessible", which could be defined simply as {{{#!hs inaccessible :: a inaccessible = error "inaccessible" }}} in `GHC.Prim` or something. This would seem like very little work, and a correspondingly tiny patch, but with quite a large payoff. Future work in automatically detecting inaccessible cases would not make existing code using this style wrong, it just means that we have to write fewer inaccessible cases by hand; but even with more sophisticated inference algorithms for inaccessible cases there will still be inaccessible cases remaining. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 16:01:09 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 16:01:09 -0000 Subject: [GHC] #10756: Allow users to indicate inaccessible patterns In-Reply-To: <044.44fc866587983798150a57353bc7bdbd@haskell.org> References: <044.44fc866587983798150a57353bc7bdbd@haskell.org> Message-ID: <059.304954dc0e84d97a14575cf87efdbc7d@haskell.org> #10756: Allow users to indicate inaccessible patterns -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 16:18:07 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 16:18:07 -0000 Subject: [GHC] #10678: integer-gmp's runS seems unnecessarily expensive In-Reply-To: <047.1e3027d49179affc6473e88cc8dec51a@haskell.org> References: <047.1e3027d49179affc6473e88cc8dec51a@haskell.org> Message-ID: <062.71357b7d78346ae16b5fe125504d8903@haskell.org> #10678: integer-gmp's runS seems unnecessarily expensive -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Interesting. DO do this less manually we would need two things: * The expression `runRW e` has the CPR property if `e rw` has the nested CPR property. * That might lead us to w/w a function like `plusBigNat` which in turn would lead to expressions like {{{ case (runRW e) of BN# farr -> farr }}} we would need some kind of special case to push the `case` inside the `runRW` to get {{{ runRW (\s -> case e s of (# s', r #) -> case r of BN# farr -> (# s', farr #) }}} That does not look too hard. It'd be good to resurrect nested CPR (there's a ticket for that, #1600). Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 16:18:44 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 16:18:44 -0000 Subject: [GHC] #10678: integer-gmp's runS seems unnecessarily expensive In-Reply-To: <047.1e3027d49179affc6473e88cc8dec51a@haskell.org> References: <047.1e3027d49179affc6473e88cc8dec51a@haskell.org> Message-ID: <062.0b4bd576ba4c7b99bc38637ec45a5708@haskell.org> #10678: integer-gmp's runS seems unnecessarily expensive -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Anyway let's land `runRW`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 16:57:24 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 16:57:24 -0000 Subject: [GHC] #10487: DeriveGeneric breaks when the same data name is used in different modules In-Reply-To: <051.f823b016355f38c348182e98da9d4ae1@haskell.org> References: <051.f823b016355f38c348182e98da9d4ae1@haskell.org> Message-ID: <066.57fee3bc1b11505442d6d78abafe9308@haskell.org> #10487: DeriveGeneric breaks when the same data name is used in different modules -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1081 -------------------------------------+------------------------------------- Comment (by dreixel): The generated datatypes do not have to be user-visible. As for using DataKinds in generics, I wouldn't really call it a clean up task, as I think there's some bit of design left to do. Anyway, it's mostly described in here: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/GenericDeriving#Kindpolymorphicoverhaul -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 17:14:24 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 17:14:24 -0000 Subject: [GHC] #9588: Add `MonadPlus (Either e)` and `Alternative (Either e)` instances In-Reply-To: <042.81b9305fea59cb0eb6b8168a5d80498d@haskell.org> References: <042.81b9305fea59cb0eb6b8168a5d80498d@haskell.org> Message-ID: <057.df54f198560ffb847c4d94e01319de67@haskell.org> #9588: Add `MonadPlus (Either e)` and `Alternative (Either e)` instances -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: ? Component: Core Libraries | Version: Resolution: | Keywords: report- | impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10755 | Differential Revisions: -------------------------------------+------------------------------------- Description changed by ekmett: Old description: > The following 2 instances are currently Orphans in `transformers` but > shall be defined in `base` instead: > > {{{#!hs > instance MonadPlus (Either e) > instance Alterantive (Either e) > }}} > > This proposal by SPJ already passed the CLC back in April and only needs > implementing. I'll submit a patch shortly to Phab New description: The following 2 instances are currently Orphans in `transformers` but could be defined in `base` without instead: {{{#!hs instance Error e => MonadPlus (Either e) instance Error e => Alterantive (Either e) }}} This would, however, require us to move `Error` from `transformers` into base, which may be a controversial move. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 17:15:43 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 17:15:43 -0000 Subject: [GHC] #9588: Add `MonadPlus (Either e)` and `Alternative (Either e)` instances In-Reply-To: <042.81b9305fea59cb0eb6b8168a5d80498d@haskell.org> References: <042.81b9305fea59cb0eb6b8168a5d80498d@haskell.org> Message-ID: <057.fd8a2e916731995a899b1f67df2e0548@haskell.org> #9588: Add `MonadPlus (Either e)` and `Alternative (Either e)` instances -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: ? Component: Core Libraries | Version: Resolution: | Keywords: report- | impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10755 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): I've updated the description to note that the CLC approved the IO instances unconditionally, but expressed reservations about the Either instances. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 18:18:43 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 18:18:43 -0000 Subject: [GHC] #10677: slightly silly assembly for testing whether a Word# is 0## In-Reply-To: <047.666ef36ac1cc91ac56611c092c7fbb22@haskell.org> References: <047.666ef36ac1cc91ac56611c092c7fbb22@haskell.org> Message-ID: <062.9d201fe16bf97b105f2e99033b08f9bc@haskell.org> #10677: slightly silly assembly for testing whether a Word# is 0## -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10750 | Differential Revisions: Phab:D1137 -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:3 nomeata]: > Is there a good way to have test cases for these issues? Maybe grep `-ddump-opt-cmm` output for the condition `if (%MO_F_Gt_W64(...` and check that it compares something to 0, not 1? Replying to [comment:4 nomeata]: > I tried to fix this, but now (presumably due to a later optimization) it produces > > {{{ > testq %r14,%r14 > jne _cQl > }}} > > I hope that is ok as well. Yes, that's just as good (generally speaking, in any particular case one may be better than the other because they imply different basic block layouts, but understanding that is a whole separate issue). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 19:03:17 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 19:03:17 -0000 Subject: [GHC] #10757: ghci panic: floatExpr tick break<1062>() Message-ID: <045.3b3833fd1a2cb60acb41c66208feed3c@haskell.org> #10757: ghci panic: floatExpr tick break<1062>() -------------------------------------+------------------------------------- Reporter: kjslag | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: panic ghci | Operating System: Unknown/Multiple optimisation | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Loading a file with {-# OPTIONS -O #-} in ghci causes a panic. See details below. $ cat panic.hs {-# OPTIONS -O #-} main :: IO () main = return () $ ghci GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help Prelude> :load panic.hs [1 of 1] Compiling Main ( panic.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): floatExpr tick break<0>() 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 Aug 7 19:05:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 19:05:05 -0000 Subject: [GHC] #10757: ghci panic: floatExpr tick break<1062>() In-Reply-To: <045.3b3833fd1a2cb60acb41c66208feed3c@haskell.org> References: <045.3b3833fd1a2cb60acb41c66208feed3c@haskell.org> Message-ID: <060.a76ece6d12758c7bde91a5274fc4fc3d@haskell.org> #10757: ghci panic: floatExpr tick break<1062>() -------------------------------------+------------------------------------- Reporter: kjslag | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: panic ghci | optimisation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by kjslag: Old description: > Loading a file with {-# OPTIONS -O #-} in ghci causes a panic. See > details below. > > $ cat panic.hs > {-# OPTIONS -O #-} > main :: IO () > main = return () > > $ ghci > GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help > Prelude> :load panic.hs > [1 of 1] Compiling Main ( panic.hs, interpreted ) > ghc: panic! (the 'impossible' happened) > (GHC version 7.10.2 for x86_64-unknown-linux): > floatExpr tick break<0>() > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug New description: Loading a file with {-# OPTIONS -O #-} in ghci causes a panic. See details below. {{{ $ cat panic.hs {-# OPTIONS -O #-} main :: IO () main = return () $ ghci GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help Prelude> :load panic.hs [1 of 1] Compiling Main ( panic.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): floatExpr tick break<0>() 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 Aug 7 19:06:09 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 19:06:09 -0000 Subject: [GHC] #10757: ghci optimisation panic: floatExpr tick break<0>() (was: ghci panic: floatExpr tick break<1062>()) In-Reply-To: <045.3b3833fd1a2cb60acb41c66208feed3c@haskell.org> References: <045.3b3833fd1a2cb60acb41c66208feed3c@haskell.org> Message-ID: <060.ba090d7780d4a4333ec7470e7816dd99@haskell.org> #10757: ghci optimisation panic: floatExpr tick break<0>() -------------------------------------+------------------------------------- Reporter: kjslag | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: panic ghci | optimisation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 7 22:31:04 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Aug 2015 22:31:04 -0000 Subject: [GHC] #10665: INLINE breaks rewrite rules when '-g' is used In-Reply-To: <045.95657d2fca941df9621daef19a7fe710@haskell.org> References: <045.95657d2fca941df9621daef19a7fe710@haskell.org> Message-ID: <060.8007c0282fe0a41cb23ca8fd48542431@haskell.org> #10665: INLINE breaks rewrite rules when '-g' is used -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2-rc2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by slyfox): Replying to [comment:4 simonpj]: > Meanwhile, can you confirm fixed in HEAD? HEAD works. Thank you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 00:38:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 00:38:14 -0000 Subject: [GHC] #10756: Allow users to indicate inaccessible patterns In-Reply-To: <044.44fc866587983798150a57353bc7bdbd@haskell.org> References: <044.44fc866587983798150a57353bc7bdbd@haskell.org> Message-ID: <059.6842e50f308725756cf10a038fec3298@haskell.org> #10756: Allow users to indicate inaccessible patterns -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * cc: george.karachalias@? (added) Comment: I like this idea (although may wish to debate the concrete syntax). But I'd like to hear input from the folks who are implementing the enhanced pattern-exhaustiveness check first. I've cc'd the lead author of that work. Any thoughts, George? When do you expect your patch to land? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 05:36:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 05:36:45 -0000 Subject: [GHC] #10758: the 'impossible' happened Message-ID: <047.37b581444bb3e575a84764414bc55658@haskell.org> #10758: the 'impossible' happened -------------------------------------------+------------------------------- Reporter: martinmr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+------------------------------- I was working on solving problems 64 and 65 of the Euler project. When I was working on problem 64 I was able to load the file into ghci. I finished the problem and moved on to problem 65. When I tried to load 65.hs in ghci I got ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): floatExpr tick break<6>() Same thing happened when I tried to load 64.hs (which used to work fine) and a number of other files from problems I had previously solved. Not all files trigger this issue and I have not changed ghc or cabal at all apart from installing the arithmoi and parallel packages. I am attaching my code for problems 64 and 65 in case my code is somehow triggering the bug (you can look at the problem statement at https://projecteuler.net/problem=64 and https://projecteuler.net/problem=65) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 05:37:12 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 05:37:12 -0000 Subject: [GHC] #10758: the 'impossible' happened In-Reply-To: <047.37b581444bb3e575a84764414bc55658@haskell.org> References: <047.37b581444bb3e575a84764414bc55658@haskell.org> Message-ID: <062.ba66be87455258107016ada3e8f91781@haskell.org> #10758: the 'impossible' happened -------------------------------+------------------------------------------- Reporter: martinmr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+------------------------------------------- Changes (by martinmr): * Attachment "64.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 05:37:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 05:37:24 -0000 Subject: [GHC] #10758: the 'impossible' happened In-Reply-To: <047.37b581444bb3e575a84764414bc55658@haskell.org> References: <047.37b581444bb3e575a84764414bc55658@haskell.org> Message-ID: <062.b806a7546d9c5207bf347c9d6ecc85ed@haskell.org> #10758: the 'impossible' happened -------------------------------+------------------------------------------- Reporter: martinmr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+------------------------------------------- Changes (by martinmr): * Attachment "65.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 05:38:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 05:38:37 -0000 Subject: [GHC] #10758: the 'impossible' happened In-Reply-To: <047.37b581444bb3e575a84764414bc55658@haskell.org> References: <047.37b581444bb3e575a84764414bc55658@haskell.org> Message-ID: <062.9031a8a14445915c7ee9bcdeeb8ed8c1@haskell.org> #10758: the 'impossible' happened -------------------------------+----------------------------------------- Reporter: martinmr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Changes (by martinmr): * architecture: Unknown/Multiple => x86_64 (amd64) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 06:30:55 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 06:30:55 -0000 Subject: [GHC] #10758: the 'impossible' happened In-Reply-To: <047.37b581444bb3e575a84764414bc55658@haskell.org> References: <047.37b581444bb3e575a84764414bc55658@haskell.org> Message-ID: <062.2ec5bdef0ba073ba4bc693c11d21ece3@haskell.org> #10758: the 'impossible' happened -------------------------------+----------------------------------------- Reporter: martinmr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by martinmr): running :set -fobject-code in ghci seems to fix the problem for now. I am still not sure why it used to work without having to set the flag. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 07:30:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 07:30:24 -0000 Subject: [GHC] #10677: slightly silly assembly for testing whether a Word# is 0## In-Reply-To: <047.666ef36ac1cc91ac56611c092c7fbb22@haskell.org> References: <047.666ef36ac1cc91ac56611c092c7fbb22@haskell.org> Message-ID: <062.7e3ec1b7870a5833180b141e9fa65656@haskell.org> #10677: slightly silly assembly for testing whether a Word# is 0## -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10750 | Differential Revisions: Phab:D1137 -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"92f35cd9829db7555397aa3dc8cd243d17694fee/ghc" 92f35cd9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="92f35cd9829db7555397aa3dc8cd243d17694fee" cmmCreateSwitchPlan: Handle singletons up-front and make sure these are implemented with an equality check, which is a shorter instruction. This was suggested by rwbarton in #10677. Differential Revision: https://phabricator.haskell.org/D1137 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 07:31:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 07:31:44 -0000 Subject: [GHC] #10744: Allow oneShot to work with unboxed types In-Reply-To: <043.1a18f79737236ccee17a4841dc4bdcd8@haskell.org> References: <043.1a18f79737236ccee17a4841dc4bdcd8@haskell.org> Message-ID: <058.f314e6f89faad4b18dafb0a8b80571a5@haskell.org> #10744: Allow oneShot to work with unboxed types -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1136 -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed Comment: Voila, akio. Hack away! And let me know if `oneShot` makes a difference for your use case, I?d like to report on it in my thesis, which marginally mentions `oneShot` as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 07:31:47 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 07:31:47 -0000 Subject: [GHC] #10677: slightly silly assembly for testing whether a Word# is 0## In-Reply-To: <047.666ef36ac1cc91ac56611c092c7fbb22@haskell.org> References: <047.666ef36ac1cc91ac56611c092c7fbb22@haskell.org> Message-ID: <062.92febef6d403a93599896acfb18a3b0c@haskell.org> #10677: slightly silly assembly for testing whether a Word# is 0## -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10750 | Differential Revisions: Phab:D1137 -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 07:32:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 07:32:20 -0000 Subject: [GHC] #10744: Allow oneShot to work with unboxed types In-Reply-To: <043.1a18f79737236ccee17a4841dc4bdcd8@haskell.org> References: <043.1a18f79737236ccee17a4841dc4bdcd8@haskell.org> Message-ID: <058.15509c0ab2d23f00cfe590b96f92c5b6@haskell.org> #10744: Allow oneShot to work with unboxed types -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1136 -------------------------------------+------------------------------------- Comment (by nomeata): Darn, wrong ticket number in commit message. This is fixed in changeset:92f35cd9829db7555397aa3dc8cd243d17694fee -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 08:18:27 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 08:18:27 -0000 Subject: [GHC] #10672: checkProddableBlock crash during Template Haskell linking In-Reply-To: <045.04cee7c60b130b0ccc29791ed61c4f5f@haskell.org> References: <045.04cee7c60b130b0ccc29791ed61c4f5f@haskell.org> Message-ID: <060.ce8733828c1ef4c14941ad59147c535e@haskell.org> #10672: checkProddableBlock crash during Template Haskell linking -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #9297 #10563 | Differential Revisions: #8237 #9907 | -------------------------------------+------------------------------------- Comment (by lukexi): To anyone else bitten by this: While this is figured out, I'm just stripping out all uses of Template Haskell in my software since I'm only using it for generating lenses. I put up a simple preprocessor here to do that during the build phase https://github.com/lukexi/strip-ths, designed to work with stack or cabal. (this workaround works because, as I mention in the README for the repro, > Everything also works [...] if I just call cabal exec -- ghc app/Main.hs. This is presumably because GHC doesn't try to link cxxylib when it is just compiling the Template Haskell splices, whereas Cabal asks it to. ) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 08:33:26 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 08:33:26 -0000 Subject: [GHC] #10754: truncate /= double2Int In-Reply-To: <043.90ddeb54230f66037ee120962cf0eb95@haskell.org> References: <043.90ddeb54230f66037ee120962cf0eb95@haskell.org> Message-ID: <058.65ed51c1013639705e7d0af7a9354654@haskell.org> #10754: truncate /= double2Int -------------------------------------+------------------------------------- Reporter: cblp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: truncate, | double2Int, rewrite, rule Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): One could even argue here that neither answer is in fact correct in light of the description of `truncate`, > `truncate x` returns the integer nearest `x` between zero and `x` In this case `truncate infinity` should be `maxBound :: Int`, no? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 08:41:56 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 08:41:56 -0000 Subject: [GHC] #10756: Allow users to indicate inaccessible patterns In-Reply-To: <044.44fc866587983798150a57353bc7bdbd@haskell.org> References: <044.44fc866587983798150a57353bc7bdbd@haskell.org> Message-ID: <059.1737f881a0b643364c541522731fa096@haskell.org> #10756: Allow users to indicate inaccessible patterns -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Also, kosmikus has suggested that the syntax proposed above looks a bit too similar to a usual RHS. [https://github.com/idris-lang/Idris-dev/wiki /Unofficial-FAQ#where-is-agdas--pattern-and-what-is-impossible Idris], for instance, has a very clearly different syntax for this, {{{ f : Num a => (n : Nat) -> Vect n a -> Nat f Z [] = 0 f Z (_::_) impossible f (S n) (x::xs) = x + f n xs f (S _) [] impossible }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 08:46:13 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 08:46:13 -0000 Subject: [GHC] #10754: truncate /= double2Int In-Reply-To: <043.90ddeb54230f66037ee120962cf0eb95@haskell.org> References: <043.90ddeb54230f66037ee120962cf0eb95@haskell.org> Message-ID: <058.3c519889625e3d7a323f029ef22cae95@haskell.org> #10754: truncate /= double2Int -------------------------------------+------------------------------------- Reporter: cblp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: truncate, | double2Int, rewrite, rule Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by cblp): Infinity is not representable in Int. Maybe maxBound is the closest answer, and they both must return maxBound, maybe they both must throw an exception. I don't know the precise answer. But I know they must return the same value, or it must be documented as undefined behaviour. Currently this rule is invalid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 08:54:13 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 08:54:13 -0000 Subject: [GHC] #10754: truncate /= double2Int In-Reply-To: <043.90ddeb54230f66037ee120962cf0eb95@haskell.org> References: <043.90ddeb54230f66037ee120962cf0eb95@haskell.org> Message-ID: <058.9b441270b6a48720b0e8b6dda3b044c6@haskell.org> #10754: truncate /= double2Int -------------------------------------+------------------------------------- Reporter: cblp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: truncate, | double2Int, rewrite, rule Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by cblp): Speaking mathematically, yes, as 1/0 is actually +infinity, nearest Int is maxBound, and for (-1/0) the nearest Int is minBound. But what is the correct answer for {{{truncate (1/0) :: Integer}}}? Now it is 179769313486231590772930519078902473361797697894230657273430081157732675805500963132708477322407536021120113879871393357658789768814416622492847430639474124377767893424865485276302219601246094119453082952085005768838150682342462881473913110540827237163350510684586298239947245938479716304835356329624224137216. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 09:47:21 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 09:47:21 -0000 Subject: [GHC] #10757: ghci optimisation panic: floatExpr tick break<0>() In-Reply-To: <045.3b3833fd1a2cb60acb41c66208feed3c@haskell.org> References: <045.3b3833fd1a2cb60acb41c66208feed3c@haskell.org> Message-ID: <060.d48df44145ac57586369810c13eb4d9b@haskell.org> #10757: ghci optimisation panic: floatExpr tick break<0>() -------------------------------------+------------------------------------- Reporter: kjslag | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: duplicate | Keywords: panic ghci | optimisation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10549 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate * related: => #10549 Comment: This is a duplicate of #10549, which has been fixed in master. I'll mark is as `merge` to ensure the fix makes it in to 7.10.3 in the event that one is released. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 09:47:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 09:47:33 -0000 Subject: [GHC] #10757: ghci optimisation panic: floatExpr tick break<0>() In-Reply-To: <045.3b3833fd1a2cb60acb41c66208feed3c@haskell.org> References: <045.3b3833fd1a2cb60acb41c66208feed3c@haskell.org> Message-ID: <060.cfeff3c642148c0578073f5f6f914968@haskell.org> #10757: ghci optimisation panic: floatExpr tick break<0>() -------------------------------------+------------------------------------- Reporter: kjslag | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: duplicate | Keywords: panic ghci | optimisation Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10549 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * failure: None/Unknown => Compile-time crash -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 09:47:55 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 09:47:55 -0000 Subject: [GHC] #10549: floatExpr tick break<2> In-Reply-To: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> References: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> Message-ID: <066.2d56019cc9729f85f81b1dcd67082391@haskell.org> #10549: floatExpr tick break<2> -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: bgamari Type: bug | Status: merge Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T10549 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1128 -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 11:44:09 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 11:44:09 -0000 Subject: [GHC] #10540: Showing type synonym isn't exported by Hoopl In-Reply-To: <045.568b20c4b6f46120dd716a4e54f79d74@haskell.org> References: <045.568b20c4b6f46120dd716a4e54f79d74@haskell.org> Message-ID: <060.76665355aab83220ea2a61bc360ce84b@haskell.org> #10540: Showing type synonym isn't exported by Hoopl -------------------------------------+------------------------------------- Reporter: nimnul | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/hoopl | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: See pull request https://github.com/haskell/hoopl/pull/13 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 11:45:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 11:45:30 -0000 Subject: [GHC] #9853: Stateful transformation causes non-termination in Hoopl analysis. In-Reply-To: <053.2d239df8bf190457291ca13b6378af1c@haskell.org> References: <053.2d239df8bf190457291ca13b6378af1c@haskell.org> Message-ID: <068.aef5d824dbd2398268ea116ab3dee073@haskell.org> #9853: Stateful transformation causes non-termination in Hoopl analysis. -------------------------------------+------------------------------------- Reporter: AndreasVoellmy | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/hoopl | Version: 7.8.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate Comment: This ticket has been migrated to the Github issue tracker: https://github.com/haskell/hoopl/issues/1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 12:27:46 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 12:27:46 -0000 Subject: [GHC] #7374: rule not firing In-Reply-To: <044.acff8d27aac517b0ec7591b52176639d@haskell.org> References: <044.acff8d27aac517b0ec7591b52176639d@haskell.org> Message-ID: <059.52e75c954b68b7fabac46ca67fecbbbf@haskell.org> #7374: rule not firing -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 12:30:25 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 12:30:25 -0000 Subject: [GHC] #10417: Rule matching not "seeing through" floating and type lambda (and maybe cast) In-Reply-To: <045.547298c8cb37685b01e9dab587a5f31f@haskell.org> References: <045.547298c8cb37685b01e9dab587a5f31f@haskell.org> Message-ID: <060.33a5f97dbe5e63664c3787bc05e70e76@haskell.org> #10417: Rule matching not "seeing through" floating and type lambda (and maybe cast) -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 12:38:08 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 12:38:08 -0000 Subject: [GHC] #7398: RULES don't apply to a newtype constructor In-Reply-To: <046.1bb2e495c45c32508f69b7364d934e7b@haskell.org> References: <046.1bb2e495c45c32508f69b7364d934e7b@haskell.org> Message-ID: <061.970d61af0e9af1b807651333b96cf11c@haskell.org> #7398: RULES don't apply to a newtype constructor -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #6082, #10418 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * failure: Incorrect result at runtime => Runtime performance bug Comment: Since RULES are usually (always?) defined for performance reasons, I'm grouping this with all other [https://ghc.haskell.org/trac/ghc/query?status=!closed&failure=Runtime+performance+bug runtime performance bugs]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 12:55:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 12:55:19 -0000 Subject: [GHC] #8178: Need TypeRep for Symbol and numeric type literals; and Typeable instances In-Reply-To: <046.4b205ddbffbf6f4b6b81f3fffe9b7560@haskell.org> References: <046.4b205ddbffbf6f4b6b81f3fffe9b7560@haskell.org> Message-ID: <061.80a2c682b1fe1eb98b8eee26bfd52859@haskell.org> #8178: Need TypeRep for Symbol and numeric type literals; and Typeable instances -------------------------------------+------------------------------------- Reporter: simonpj | Owner: diatchki 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 | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: This works with ghc-7.10.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 13:12:38 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 13:12:38 -0000 Subject: [GHC] #8995: When generalising, use levels rather than global tyvars In-Reply-To: <046.9987efe4c8232a1075e003930ca5ea84@haskell.org> References: <046.9987efe4c8232a1075e003930ca5ea84@haskell.org> Message-ID: <061.66c7e5d82f82f8d6136ad01df54b337d@haskell.org> #8995: When generalising, use levels rather than global tyvars -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 14:10:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 14:10:37 -0000 Subject: [GHC] #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` In-Reply-To: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> References: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> Message-ID: <057.6b828f351cd32d5cc57e76ce731aa7a8@haskell.org> #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | simplCore/should_compile/T8832 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): The problem here is that the `Bits` instance for `Integer` overrides `bit`, using it's own `bitInteger` function in place of the usual `bitDefault`. `bitDefault` is constant folded by `PrelRules` by virtue of being implemented in terms of `shiftL`. This is presumably done to optimize the case of construction of a `BigNat` for large arguments, but `bitBigNat#`, which is what handles this case, is currently just the naive implementation with a TODO. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 14:14:07 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 14:14:07 -0000 Subject: [GHC] #10726: Upgrade MingW-w64 distributions for windows In-Reply-To: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> References: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> Message-ID: <059.3d194101e3ba0ebc87a4c3dc683d0550@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: patch Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #9014 | Differential Revisions: Phab:D1123 #10435 | -------------------------------------+------------------------------------- Comment (by Phyx-): I've updated the toolchains to 5.2.0. Validate on `x86_64` looks good again, still fixing a few tests on `x86`. See Phabricator. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 15:07:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 15:07:24 -0000 Subject: [GHC] #10759: don't throw BlockedIndefinitelyOn... in main thread Message-ID: <044.e96ca394fd0ec7f5ab2bd63075d05667@haskell.org> #10759: don't throw BlockedIndefinitelyOn... in main thread -------------------------------------+------------------------------------- Reporter: yokto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- In the main thread UserInterrupt can be thrown to unblock a thread. So the following program should wait for such an interrupt instead of throwing a BlockedIndefinitelyOnMVar exception {{{ main = do var <- newEmptyMVar takeMVar var `catch` (const $ putStrLn "UserInterrupt caught" :: AsyncException -> IO ()) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 15:52:06 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 15:52:06 -0000 Subject: [GHC] #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 In-Reply-To: <047.bc42599240078110c16528fec3996433@haskell.org> References: <047.bc42599240078110c16528fec3996433@haskell.org> Message-ID: <062.8648c9d508ab60054f0d33a7c8045d31@haskell.org> #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 -------------------------------------+------------------------------------- Reporter: malcolmw | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: windows, | exceptions Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #10726 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Phyx-): This will be fixed when #10726 is committed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 17:00:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 17:00:10 -0000 Subject: [GHC] #10760: Conflicting typefamily instances not reported with polykinds Message-ID: <045.f668c555ecaf923aed62f73fe3fd8413@haskell.org> #10760: Conflicting typefamily instances not reported with polykinds -------------------------------------+------------------------------------- Reporter: steely | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- GHC fails to report conflicting instances for a open polykinded type family when the two resulting types have different kinds. I would expect conflicts to be detected regardless of the concrete kind of the result. Minimal Example: {{{#!hs type family Bar a :: k type instance Bar Int = Int --type instance Bar Int = Bool -- Conflict detected type instance Bar Int = [] -- Conflict NOT detected }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 18:33:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 18:33:42 -0000 Subject: [GHC] #10760: Conflicting typefamily instances not reported with polykinds In-Reply-To: <045.f668c555ecaf923aed62f73fe3fd8413@haskell.org> References: <045.f668c555ecaf923aed62f73fe3fd8413@haskell.org> Message-ID: <060.e853e92fac18eb73c4397bc845f6c2d5@haskell.org> #10760: Conflicting typefamily instances not reported with polykinds -------------------------------------+------------------------------------- Reporter: steely | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => invalid Comment: This is correct behavior. All kind variables in a type family are always inputs. This is admittedly counter-intuitive when the kind variable classifies the result. If we write kinds explicitly, your example becomes this: {{{ type family Bar k (a :: *) :: k type instance Bar * Int = Int type instance Bar (* -> *) Int = [] }}} If you have a concrete suggestion of how to improve the manual in this regard, we'd love to have it. Thanks for reporting! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 19:33:07 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 19:33:07 -0000 Subject: [GHC] #10672: checkProddableBlock crash during Template Haskell linking In-Reply-To: <045.04cee7c60b130b0ccc29791ed61c4f5f@haskell.org> References: <045.04cee7c60b130b0ccc29791ed61c4f5f@haskell.org> Message-ID: <060.1fc229036842a7e1981824310930199b@haskell.org> #10672: checkProddableBlock crash during Template Haskell linking -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #9297 #10563 | Differential Revisions: #8237 #9907 | -------------------------------------+------------------------------------- Changes (by JohnWiegley): * cc: JohnWiegley (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 20:42:59 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 20:42:59 -0000 Subject: [GHC] #10487: DeriveGeneric breaks when the same data name is used in different modules In-Reply-To: <051.f823b016355f38c348182e98da9d4ae1@haskell.org> References: <051.f823b016355f38c348182e98da9d4ae1@haskell.org> Message-ID: <066.290439984b7e8e767b5fc1efac73c7d8@haskell.org> #10487: DeriveGeneric breaks when the same data name is used in different modules -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1081 -------------------------------------+------------------------------------- Comment (by osa1): I fixed name generation and the patch is ready for reviews. Only missing thing is a test for package imports. Does anyone know if it's possible to add a test with packages without modifying test driver? (`driver/runtests.py`) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 22:03:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 22:03:14 -0000 Subject: [GHC] #10761: GHC panic when compiling vimus: failed to map segment from shared object Message-ID: <044.348040be7af1c5ddfaac6540d862ffb8@haskell.org> #10761: GHC panic when compiling vimus: failed to map segment from shared object -------------------------------------+------------------------------------- Reporter: haasn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When trying to build https://github.com/vimus/vimus I get a GHC panic on a specific module: {{{ ? cabal build Building vimus-0.2.1... Preprocessing library vimus-0.2.1... [38 of 39] Compiling Vimus.Command ( src/Vimus/Command.hs, dist/build/Vimus/Command.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc17990_0/libghc_39.so: failed to map segment from shared object Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I don't know why it's only this particular module of this particular library that fails. I'm running a kernel with GrSecurity and PaX enabled, and am using a hardened GCC toolchain (although Gentoo seems to automatically disable PIE for Haskell packages). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 22:03:53 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 22:03:53 -0000 Subject: [GHC] #10761: GHC panic when compiling vimus: failed to map segment from shared object In-Reply-To: <044.348040be7af1c5ddfaac6540d862ffb8@haskell.org> References: <044.348040be7af1c5ddfaac6540d862ffb8@haskell.org> Message-ID: <059.29d5ef8dfe4b9a7a443c7aef1c03a98d@haskell.org> #10761: GHC panic when compiling vimus: failed to map segment from shared object -------------------------------------+------------------------------------- Reporter: haasn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by haasn: Old description: > When trying to build https://github.com/vimus/vimus I get a GHC panic on > a specific module: > > {{{ > ? cabal build > Building vimus-0.2.1... > Preprocessing library vimus-0.2.1... > [38 of 39] Compiling Vimus.Command ( src/Vimus/Command.hs, > dist/build/Vimus/Command.o ) > ghc: panic! (the 'impossible' happened) > (GHC version 7.10.2 for x86_64-unknown-linux): > Loading temp shared object failed: /tmp/ghc17990_0/libghc_39.so: > failed to map segment from shared object > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} > > I don't know why it's only this particular module of this particular > library that fails. > > I'm running a kernel with GrSecurity and PaX enabled, and am using a > hardened GCC toolchain (although Gentoo seems to automatically disable > PIE for Haskell packages). New description: When trying to build https://github.com/vimus/vimus I get a GHC panic on a specific module: {{{ ? cabal build Building vimus-0.2.1... Preprocessing library vimus-0.2.1... [38 of 39] Compiling Vimus.Command ( src/Vimus/Command.hs, dist/build/Vimus/Command.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc17990_0/libghc_39.so: failed to map segment from shared object Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I don't know why it's only this particular module of this particular library that fails. I'm running a kernel with GrSecurity and PaX enabled, and am using a hardened GCC toolchain (although Gentoo seems to automatically disable PIE for Haskell packages). That said, I checked ?dmesg? and there's no occurrence of a grsec exception. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 22:05:59 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 22:05:59 -0000 Subject: [GHC] #10761: GHC panic when compiling vimus: failed to map segment from shared object In-Reply-To: <044.348040be7af1c5ddfaac6540d862ffb8@haskell.org> References: <044.348040be7af1c5ddfaac6540d862ffb8@haskell.org> Message-ID: <059.e2908a24293ab2c211717e0587ce2562@haskell.org> #10761: GHC panic when compiling vimus: failed to map segment from shared object -------------------------------------+------------------------------------- Reporter: haasn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by haasn): Update: Turns out this particular failure was caused by /tmp being mounted ?noexec?. I've remounted it without that option and now I get a different panic in the same place: {{{ [38 of 39] Compiling Vimus.Command ( src/Vimus/Command.hs, dist/build/Vimus/Command.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc18764_0/libghc_39.so: undefined symbol: nm_getyx }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 22:27:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 22:27:51 -0000 Subject: [GHC] #10761: GHC panic when compiling vimus: failed to map segment from shared object In-Reply-To: <044.348040be7af1c5ddfaac6540d862ffb8@haskell.org> References: <044.348040be7af1c5ddfaac6540d862ffb8@haskell.org> Message-ID: <059.e1407d675d13371b61cb6517cc56d1bf@haskell.org> #10761: GHC panic when compiling vimus: failed to map segment from shared object -------------------------------------+------------------------------------- Reporter: haasn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by haasn): Seems to be related to template haskell. Removing the QuasiQuotes extension (and the lines that rely on it) makes it build successfully. I haven't been able to construct a minimal reproduction, though, even one that uses QuasiQuotes. So I'm not sure what else is needed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 8 23:05:16 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 23:05:16 -0000 Subject: [GHC] #10761: GHC panic when compiling vimus: failed to map segment from shared object In-Reply-To: <044.348040be7af1c5ddfaac6540d862ffb8@haskell.org> References: <044.348040be7af1c5ddfaac6540d862ffb8@haskell.org> Message-ID: <059.8ab544803a4594f5a0d44f8d248829e9@haskell.org> #10761: GHC panic when compiling vimus: failed to map segment from shared object -------------------------------------+------------------------------------- Reporter: haasn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by haasn): rwbarton came up with a minimal reproduction: A.hs {{{ module A where foreign import ccall "foo" foo :: IO () bar :: IO () bar = print "hi!" {-# NOINLINE bar #-} }}} B.hs {{{ {-# LANGUAGE TemplateHaskell #-} module B where import Language.Haskell.TH.Syntax import A $(runIO bar >> return []) }}} ghc A.hs B.hs {{{ [1 of 2] Compiling A ( A.hs, A.o ) [2 of 2] Compiling B ( B.hs, B.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc23866_0/libghc_7.so: undefined symbol: foo 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 Sat Aug 8 23:23:06 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Aug 2015 23:23:06 -0000 Subject: [GHC] #10761: GHC panic when compiling vimus: failed to map segment from shared object In-Reply-To: <044.348040be7af1c5ddfaac6540d862ffb8@haskell.org> References: <044.348040be7af1c5ddfaac6540d862ffb8@haskell.org> Message-ID: <059.142a2761b97872a283d9ddc42bcd0137@haskell.org> #10761: GHC panic when compiling vimus: failed to map segment from shared object -------------------------------------+------------------------------------- Reporter: haasn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by haasn): I figured out how to trigger whether or not that sample fails: It works if I switch to the ?vanilla? GCC profile (x86_64-pc-linux- gnu-4.9.3-vanilla, which has no hardening options enabled). It fails if I switch to the ?hardened? GCC profile , even if I pick a version that has PIE and SSP disabled by default (x86_64-pc-linux- gnu-4.9.3-hardenednopiessp). So this particular failure, apart from potentially being a bug in either vimus or Cabal, is also triggered by the usage of hardened GCC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 9 01:36:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Aug 2015 01:36:34 -0000 Subject: [GHC] #10761: GHC panic when compiling vimus: failed to map segment from shared object In-Reply-To: <044.348040be7af1c5ddfaac6540d862ffb8@haskell.org> References: <044.348040be7af1c5ddfaac6540d862ffb8@haskell.org> Message-ID: <059.dd5a0073c2ef34d66fec304dfc0c35f9@haskell.org> #10761: GHC panic when compiling vimus: failed to map segment from shared object -------------------------------------+------------------------------------- Reporter: haasn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by haasn): Works with {{{-optl -Wl,-z,lazy}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 9 02:34:07 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Aug 2015 02:34:07 -0000 Subject: [GHC] #10761: GHC panic when compiling vimus: failed to map segment from shared object In-Reply-To: <044.348040be7af1c5ddfaac6540d862ffb8@haskell.org> References: <044.348040be7af1c5ddfaac6540d862ffb8@haskell.org> Message-ID: <059.7756af12f2d9f0e21d2184193d39cebf@haskell.org> #10761: GHC panic when compiling vimus: failed to map segment from shared object -------------------------------------+------------------------------------- Reporter: haasn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Ultimately Cabal is doing something fragile here, by invoking ghc on only the Haskell sources, and not passing it the C sources or object files. If the Haskell source contains a Template Haskell splice that actually uses a function defined in a C source file then this can't possibly ever work. If there is a Template Haskell splice that uses another module from the current package that also happens imports a function from a C source file, this might work depending on the details of the linker. The temporary shared object loaded to run the splice will certainly contain an undefined symbol, but this may or may not be a problem. Relevant factors include * Whether the library is marked for lazy binding of functions (PLT references). If the binding is lazy, then the load will not fail and the Template Haskell splice runner will be able to use the shared library as long as it does not actually need to call the function in question. If the binding is not lazy then the load will fail (`Loading temp shared object failed: [...] undefined symbol: [...]`). Lazy binding is normally the default but in some hardened systems or build environments such as haasn's it is not. * Whether the foreign call refers to the C symbol by a PLT or GOT entry. GOT entries cannot be resolved at call time because the reference is not necessarily a call. Why would we call a C function through a GOT entry? Well if optimizations are not enabled then the code generator for an STG foreign call produces Cmm like {{{ _cJW::I64 = foobarbaz; call "ccall" arg hints: [] result hints: [] (_cJW::I64)(); }}} and to the backend this looks like a general reference to an object followed by an indirect function call. We can and probably should fix this but it doesn't fix the actual issue here. In my opinion it would make more sense for Cabal to just provide the C sources or object files to the ghc invocation. But also see https://github.com/haskell/cabal/issues/1738 which points out a problem with that idea. Should Cabal have two categories of C source files, one that consists of dependencies of the Haskell code and one that consists of source files that have foreign export stub headers as dependencies? I would think that since Cabal is intended for building Haskell libraries that the first category would be much greater... I don't know if it makes sense to do anything here in GHC besides being aware of the issue and setting `ghc-options: -optl-Wl,z,lazy` when building on systems where it is not the default as a workaround. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 9 03:11:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Aug 2015 03:11:00 -0000 Subject: [GHC] #10750: silly assembly for comparing Doubles In-Reply-To: <047.207ed991d667b8f8c95a3231e8362053@haskell.org> References: <047.207ed991d667b8f8c95a3231e8362053@haskell.org> Message-ID: <062.2f73cb66678e7b4f8e5d1256f2904847@haskell.org> #10750: silly assembly for comparing Doubles -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10137, #10677 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:2 nomeata]: > Anyways, with #10677 resp. D1137, the conditions should be `condition != 0`, which will hopefully be turned into `condition`. Yes, I believe that case is handled already. Here is an example (build with `-O`): {{{ f :: Double -> Double f x = if x > 0 then 1 else 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 9 07:59:50 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Aug 2015 07:59:50 -0000 Subject: [GHC] #10750: silly assembly for comparing Doubles In-Reply-To: <047.207ed991d667b8f8c95a3231e8362053@haskell.org> References: <047.207ed991d667b8f8c95a3231e8362053@haskell.org> Message-ID: <062.b6b760aea2eead13f9575acb8e009be1@haskell.org> #10750: silly assembly for comparing Doubles -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10137, #10677 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Weird. With your example, compiled with `./inplace/bin/ghc-stage2 -fforce-recomp -O -ddump-asm T10677.hs`, I get assembly like this: {{{ ==================== Asm code ==================== .text .align 8 .long S1vB_srt-(Zero.f_info)+0 .long 0 .quad 4294967301 .quad 0 .quad 12884901903 .globl Zero.f_info .type Zero.f_info, @object Zero.f_info: _c1vs: leaq -32(%rbp),%rax cmpq %r15,%rax jb _c1vt _c1vu: movq $block_c1vm_info,-8(%rbp) movq %r14,%rax movl $GHC.Classes.$fOrdDouble_closure,%r14d movq $stg_ap_pp_info,-32(%rbp) movq %rax,-24(%rbp) movq $Zero.f3_closure+1,-16(%rbp) addq $-32,%rbp jmp GHC.Classes.>_info .text .align 8 .quad 0 .quad 32 block_c1vm_info: _c1vm: andl $7,%ebx cmpq $1,%rbx jne _c1vq _c1vp: movl $Zero.f2_closure+1,%ebx addq $8,%rbp jmp *(%rbp) _c1vq: movl $Zero.f1_closure+1,%ebx addq $8,%rbp jmp *(%rbp) _c1vt: movl $Zero.f_closure,%ebx jmp *-8(%r13) .size Zero.f_info, .-Zero.f_info }}} so unless I am reading this wrong, it did not inline specialize or `>`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 9 08:50:02 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Aug 2015 08:50:02 -0000 Subject: [GHC] #10760: Conflicting typefamily instances not reported with polykinds In-Reply-To: <045.f668c555ecaf923aed62f73fe3fd8413@haskell.org> References: <045.f668c555ecaf923aed62f73fe3fd8413@haskell.org> Message-ID: <060.a1ff9a7fe9306d7df33659cdfa841349@haskell.org> #10760: Conflicting typefamily instances not reported with polykinds -------------------------------------+------------------------------------- Reporter: steely | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by steely): I understand. This is indeed very subtle and ought to be documented. I am not sure whether this explanation should go in the section about type families alone, since this issue is related to their interaction with PolyKinds, but anyway it would be more precise to include something like: In the paragraph about "Type Family Declarations". The result kind annotation is optional and, as usual, defaults to * if omitted. Polykinded type families can be declared using a parameter in the kind annotation: {{{ type family F a :: k }}} Note that in this case the kind parameter k is an actual implicit parameter of the type family and as such is relevant when checking the apartness of type family equations. In the paragraph about "Compatibility and apartness of type family equations'": 1. all corresponding types and '''implicit kinds''' in the patterns are apart. The example of this ticket could also be included to show this. I am not sure whether in GHC 7.10 kind variables have to be explicitly given in type families, making it more intuitive. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 9 09:29:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Aug 2015 09:29:24 -0000 Subject: [GHC] #10716: Metadata in GHC.Generic should give access to strictness annotation In-Reply-To: <049.954933c3fdc7ca9d74108b79b667adbd@haskell.org> References: <049.954933c3fdc7ca9d74108b79b667adbd@haskell.org> Message-ID: <064.e030422d5e699d1bef68cbaa677239de@haskell.org> #10716: Metadata in GHC.Generic should give access to strictness annotation -------------------------------------+------------------------------------- Reporter: StefanWehr | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by StefanWehr): == Extended API == A new class is added to `GHC.Generics`: {{{#!hs class StrictSelector s }}} This class has no methods; it only serves as a type-level constraint for a selector having a bang pattern. Also, I suggest changing the `NoSelector` type from `GHC.Generics` to accept a new type parameter: {{{#!hs data NoSelector t }}} The new type parameter is either `NoStrict` or `Strict`. These two types are also added to `GHC.Generics`: {{{#!hs data NoStrict data Strict }}} For anonymous selectors, we define an instance for `StrictSelector`: {{{#!hs instance StrictSelector (NoSelector Strict) }}} So far, this encodes strictness of a selector on the type-level. To access this information on the value-level, I suggest adding a new method to the type class `Selector` from `GHC.Generics`: {{{#!hs class Selector s where selName :: t s (f :: * -> *) a -> [Char] selIsStrict :: t s (f :: * -> *) a -> Bool -- NEW }}} My API proposal is not backwards compatible: the change to `NoSelector` will definitely break existing code, the addition of a new type class and two new data types might break existing code if the names are already used for something different. I tried avoiding the change to `NoSelector` but couldn't come up with a solution that brings the strictness (or lazyness) of a selector to the type-level. (For the application I have in mind, it's not enough to have these information on the value-level only.) == Changes to the deriving mechanism == The deriving mechanism for generics is extended in the following way: * replace occurrences of `NoSelector` with `NoSelector Strict` or `NoSelector NoStrict` * for named selectors carrying a bang pattern, generate an instance of `StrictSelector T`, where `T` is the type generated for the selector. I'm happy to provide a patch for this, but first I want to make sure that my design is reasonable. Any comments? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 9 10:16:15 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Aug 2015 10:16:15 -0000 Subject: [GHC] #10716: Metadata in GHC.Generic should give access to strictness annotation In-Reply-To: <049.954933c3fdc7ca9d74108b79b667adbd@haskell.org> References: <049.954933c3fdc7ca9d74108b79b667adbd@haskell.org> Message-ID: <064.ca8641a06ddb5ff01712443bfef7e53b@haskell.org> #10716: Metadata in GHC.Generic should give access to strictness annotation -------------------------------------+------------------------------------- Reporter: StefanWehr | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dreixel): Why can't we just add the `selIsStrict` part? To get the information at the type level we better do it for all meta-data at the same time, and we can get it when we make `GHC.Generics` use `DataKinds`, as described in https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/GenericDeriving#Kindpolymorphicoverhaul -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 9 10:58:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Aug 2015 10:58:01 -0000 Subject: [GHC] #10762: On Windows, out-of-codepage characters can cause GHC build to fail Message-ID: <047.594293f39928454a6845b64e2efaf718@haskell.org> #10762: On Windows, out-of-codepage characters can cause GHC build to fail -----------------------------------------+--------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+--------------------------------- You can see where this hit us recently on stack with issues [https://github.com/commercialhaskell/stack/issues/738 738] and [https://github.com/commercialhaskell/stack/issues/734 734]. To demonstrate, I'm attaching a UTF-8 encoded Haskell program with some Hebrew characters, and some warnings. The contents of that file are: {{{#!hs module Main ( main , ???? ) where main :: IO () main = putStrLn ???? ???? = "shalom" }}} If I first set my codepage to 65001 (UTF-8), everything works as expected: {{{ C:\Users\Michael\Desktop>chcp 65001 Active code page: 65001 C:\Users\Michael\Desktop>ghc -fforce-recomp -Wall -ddump-hi -ddump-to-file shalom.hs [1 of 1] Compiling Main ( shalom.hs, shalom.o ) shalom.hs:9:1: Warning: Top-level binding with no type signature: ???? :: [Char] Linking shalom.exe ... }}} However, if I set my codepage to 437 (US), both the warnings sent to the console, and the .hi dump file, cause GHC to exit prematurely: {{{ C:\Users\Michael\Desktop>chcp 437 Active code page: 437 C:\Users\Michael\Desktop>ghc -fforce-recomp -Wall shalom.hs [1 of 1] Compiling Main ( shalom.hs, shalom.o ) shalom.hs:9:1: Warning: Top-level binding with no type signature: : commitBuffer: invalid argument (invalid character) }}} {{{ C:\Users\Michael\Desktop>chcp 437 Active code page: 437 C:\Users\Michael\Desktop>ghc -fforce-recomp -ddump-hi -ddump-to-file shalom.hs [1 of 1] Compiling Main ( shalom.hs, shalom.o ) shalom.dump-hi: commitBuffer: invalid argument (invalid character) }}} At the very least, I would argue that -ddump-to-file should always dump to the output files as UTF-8, as this is the most useful for tooling. Beyond that, there are a few options here: * Have all output- including to the console- go out as UTF-8. This may not play terribly nicely with consoles without setting the output codepage. * Provide a command line option or environment variable to specify "output as UTF-8." * More radical: change the default way that all Handles work so that UTF-8 is the default, instead of paying attention to code pages and environment variables. Honestly, this is my preference, but it's a bigger discussion than this one bug. The workaround we've implemented in stack for now is setting the codepage to 65001 for the console while running stack. This is not ideal, since this is essentially a global setting for the entire console. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 9 10:58:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Aug 2015 10:58:10 -0000 Subject: [GHC] #10762: On Windows, out-of-codepage characters can cause GHC build to fail In-Reply-To: <047.594293f39928454a6845b64e2efaf718@haskell.org> References: <047.594293f39928454a6845b64e2efaf718@haskell.org> Message-ID: <062.964673ea5c3660b06762ab1435d648ec@haskell.org> #10762: On Windows, out-of-codepage characters can cause GHC build to fail ---------------------------------+----------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Changes (by snoyberg): * Attachment "shalom.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 9 12:48:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Aug 2015 12:48:14 -0000 Subject: [GHC] #10758: the 'impossible' happened In-Reply-To: <047.37b581444bb3e575a84764414bc55658@haskell.org> References: <047.37b581444bb3e575a84764414bc55658@haskell.org> Message-ID: <062.c574b8dd5f448c1156407667cf36c97c@haskell.org> #10758: the 'impossible' happened -------------------------------+----------------------------------------- Reporter: martinmr | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.10.2 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #10549 | Differential Revisions: -------------------------------+----------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #10549 Comment: This is a duplicate of #10549, which has been fixed in HEAD. As a workaround: remove the `OPTIONS_GHC -O` pragma from your files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 9 13:25:02 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Aug 2015 13:25:02 -0000 Subject: [GHC] #9173: Better type error messages In-Reply-To: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> References: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> Message-ID: <061.521db9f7563175e02a20db19455b2a49@haskell.org> #9173: Better type error messages -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): It seems this ticket is not as easy to fix as I thought it would be. See: https://mail.haskell.org/pipermail/ghc-devs/2015-August/009559.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 9 15:45:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Aug 2015 15:45:36 -0000 Subject: [GHC] #10762: On Windows, out-of-codepage characters can cause GHC build to fail In-Reply-To: <047.594293f39928454a6845b64e2efaf718@haskell.org> References: <047.594293f39928454a6845b64e2efaf718@haskell.org> Message-ID: <062.129720e633677bcfcb63f02eccdda7cf@haskell.org> #10762: On Windows, out-of-codepage characters can cause GHC build to fail ---------------------------------+----------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by rwbarton): To what extent do you consider your suggestions Windows-specific? Since GHC assumes that input Haskell files are always UTF-8, one could argue that `-ddump-to-file` output should always be UTF-8 as well, on every system. However producing UTF-8-encoded console output when the locale specifies a different encoding makes no sense to me, so I hope that suggestion at least is for Windows only. > The workaround we've implemented in stack for now is setting the codepage to 65001 for the console while running stack. This is not ideal, since this is essentially a global setting for the entire console. It must be my lack of experience with Windows, but I don't understand why this is considered a "workaround" rather than a basic necessity for having any kind of working system. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 9 15:54:58 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Aug 2015 15:54:58 -0000 Subject: [GHC] #10762: On Windows, out-of-codepage characters can cause GHC build to fail In-Reply-To: <047.594293f39928454a6845b64e2efaf718@haskell.org> References: <047.594293f39928454a6845b64e2efaf718@haskell.org> Message-ID: <062.8256ad0cfd848571cc5835387a7d0383@haskell.org> #10762: On Windows, out-of-codepage characters can cause GHC build to fail ---------------------------------+----------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by snoyberg): I think that all file output from GHC should be UTF-8, regardless of OS, and regardless of locale settings. I won't make too many arguments around console output, except that even on Windows, there should be some environment variable or command line switch to force UTF-8 output. As it stands, the only way to capture output reliably from GHC on Windows is to change the codepage for the entire console. And speaking of which: I won't profess to be a Windows expert myself, but from my rather painful research this morning: a console codepage is not something which is merely inherited by subprocesses (the way an environment variable is), but by other processes in the same console. Unless I'm misunderstanding something, the workaround we're using in stack now could have negative consequences for things like running stack/GHC from inside a text editor, where the text editor may suddenly have its code page changed on it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 9 15:55:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Aug 2015 15:55:29 -0000 Subject: [GHC] #10762: On Windows, out-of-codepage characters can cause GHC build to fail In-Reply-To: <047.594293f39928454a6845b64e2efaf718@haskell.org> References: <047.594293f39928454a6845b64e2efaf718@haskell.org> Message-ID: <062.1dba717a422887cbc452708acf62b7dd@haskell.org> #10762: On Windows, out-of-codepage characters can cause GHC build to fail ---------------------------------+----------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by rwbarton): (To expand on the last point: If your terminal is not actually configured to interpret console output as UTF-8 then you will not be able to read the warnings if GHC insisted on outputting UTF-8. And if it is configured to do so then why is the code page not set to 65001?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 9 15:58:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Aug 2015 15:58:41 -0000 Subject: [GHC] #10762: On Windows, out-of-codepage characters can cause GHC build to fail In-Reply-To: <047.594293f39928454a6845b64e2efaf718@haskell.org> References: <047.594293f39928454a6845b64e2efaf718@haskell.org> Message-ID: <062.1cbb9ee76fd405b3752655025d7a08a1@haskell.org> #10762: On Windows, out-of-codepage characters can cause GHC build to fail ---------------------------------+----------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by snoyberg): > (To expand on the last point: If your terminal is not actually configured to interpret console output as UTF-8 then you will not be able to read the warnings if GHC insisted on outputting UTF-8. And if it is configured to do so then why is the code page not set to 65001?) The wonders of the Windows world still mystify me, so hopefully someone more informed can chime in. However, I was able to get both the standard Windows console and ConEmu to display non-ASCII characters (limited only by my font choice) by switching codepages. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 9 16:00:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Aug 2015 16:00:57 -0000 Subject: [GHC] #10762: On Windows, out-of-codepage characters can cause GHC build to fail In-Reply-To: <047.594293f39928454a6845b64e2efaf718@haskell.org> References: <047.594293f39928454a6845b64e2efaf718@haskell.org> Message-ID: <062.f2c276f9f9092178b6e73f175bb11cd6@haskell.org> #10762: On Windows, out-of-codepage characters can cause GHC build to fail ---------------------------------+----------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by rwbarton): Well, I recognize that this is a pain point on Windows, so as long as nothing changes on non-Windows except, possibly, writing `-ddump-to-file` output in UTF-8 always, then whatever happens on Windows is fine with me... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 9 16:04:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Aug 2015 16:04:01 -0000 Subject: [GHC] #10762: On Windows, out-of-codepage characters can cause GHC build to fail In-Reply-To: <047.594293f39928454a6845b64e2efaf718@haskell.org> References: <047.594293f39928454a6845b64e2efaf718@haskell.org> Message-ID: <062.f914a84c4e4bbc943e9586e21cfa6758@haskell.org> #10762: On Windows, out-of-codepage characters can cause GHC build to fail ---------------------------------+----------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6037 | Differential Revisions: ---------------------------------+----------------------------------------- Changes (by rwbarton): * related: => #6037 Comment: See also #6037. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 9 17:52:28 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Aug 2015 17:52:28 -0000 Subject: [GHC] #1405: Make ghc (stage1) be compilable by non-GHC In-Reply-To: <051.fdfe73ce3bd8dfdeb8a04e3a7bade7ab@haskell.org> References: <051.fdfe73ce3bd8dfdeb8a04e3a7bade7ab@haskell.org> Message-ID: <066.1fb7c74265470ed75839b0182ed69167@haskell.org> #1405: Make ghc (stage1) be compilable by non-GHC -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: Type: task | Status: closed Priority: normal | Milestone: ? Component: Compiler | Version: 6.6.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => wontfix Comment: I'm slowly reverting this work. There's no point in pretending GHC can still be compiled by other compilers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 9 19:19:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Aug 2015 19:19:32 -0000 Subject: [GHC] #10750: silly assembly for comparing Doubles In-Reply-To: <047.207ed991d667b8f8c95a3231e8362053@haskell.org> References: <047.207ed991d667b8f8c95a3231e8362053@haskell.org> Message-ID: <062.0fb46ea458d6170a62da572b20a98c21@haskell.org> #10750: silly assembly for comparing Doubles -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10137, #10677 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Maybe you built GHC's libraries at too low an optimization level? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 9 20:08:43 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Aug 2015 20:08:43 -0000 Subject: [GHC] #9173: Better type error messages In-Reply-To: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> References: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> Message-ID: <061.6eb24c90b2b024b14c30d83092139975@haskell.org> #9173: Better type error messages -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: newcomer => Comment: Yes, I don't think this is easy, precisely for the reasons described in that post. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 10 03:47:10 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Aug 2015 03:47:10 -0000 Subject: [GHC] #10339: PatternSynonyms confuse exhaustiveness check In-Reply-To: <042.a1c90776a4d0c26d5af0fe09a172c987@haskell.org> References: <042.a1c90776a4d0c26d5af0fe09a172c987@haskell.org> Message-ID: <057.3e28b5c7678f521bb17901bc04a005f4@haskell.org> #10339: PatternSynonyms confuse exhaustiveness check -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by wrl314): Another example showing same problem with simple unidirectional pattern synonym: {{{ data Foo2 = Foo2 Int String pattern F a <- Foo2 a _ blah :: Foo2 -> Int blah (F a) = a + 1 }}} Result: {{{ Warning: Pattern match(es) are non-exhaustive In an equation for ?blah?: Patterns not matched: _ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 10 05:43:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Aug 2015 05:43:26 -0000 Subject: [GHC] #8101: No pattern match non-exhaustiveness warnings when compiling with -fno-code In-Reply-To: <044.dfa43534fecae23d8d03f05e2e6d901b@haskell.org> References: <044.dfa43534fecae23d8d03f05e2e6d901b@haskell.org> Message-ID: <059.bb88ac615d1a3a8380eab6a39cae39ac@haskell.org> #8101: No pattern match non-exhaustiveness warnings when compiling with -fno-code -------------------------------------+------------------------------------- Reporter: exbb2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: T8101 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by DanielG): * status: closed => new * resolution: fixed => Comment: Looks to me like this is still an issue, I couldn't actually find a released version where this was ever fixed. This is also biting us in ghc-mod land: https://github.com/kazu-yamamoto /ghc-mod/issues/507 {{{ $ ghc-7.8.1 -fno-code -fforce-recomp A.hs [1 of 1] Compiling A ( A.hs, nothing ) $ ghc-7.8.4 -fno-code -fforce-recomp A.hs [1 of 1] Compiling A ( A.hs, nothing ) $ ghc-7.10.2 -fno-code -fforce-recomp A.hs [1 of 1] Compiling A ( A.hs, nothing ) # ghc-7.8.1 -fobject-code -fforce-recomp A.hs [1 of 1] Compiling A ( A.hs, A.o ) A.hs:7:9: Warning: Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: B C $ ghc-7.8.4 -fobject-code -fforce-recomp A.hs [1 of 1] Compiling A ( A.hs, A.o ) A.hs:7:9: Warning: Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: B C $ ghc-7.10.2 -fobject-code -fforce-recomp A.hs [1 of 1] Compiling A ( A.hs, A.o ) A.hs:7:9: Warning: Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: B C }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 10 05:53:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Aug 2015 05:53:47 -0000 Subject: [GHC] #10762: On Windows, out-of-codepage characters can cause GHC build to fail In-Reply-To: <047.594293f39928454a6845b64e2efaf718@haskell.org> References: <047.594293f39928454a6845b64e2efaf718@haskell.org> Message-ID: <062.031dfa25dd2a9a1621d662a54aa8a50c@haskell.org> #10762: On Windows, out-of-codepage characters can cause GHC build to fail ---------------------------------+----------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6037 | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by snoyberg): After this discussion, here's the proposal I'd make, which is a libraries change, not just a GHC-internal change: * The default filesystem encoding will always be UTF-8, regardless of environment variables or codepage * We modify the encoding logic on Windows to also respect an environment variable (perhaps LANG, not sure) to override the codepage for stdin/stdout/stderr character encoding One I'm on the fence about: * Modify the character encoding codepaths to not throw an exception on an unhandled character when using the default encoding for stdin/stdout/stderr. This would be nice in that GHC wouldn't die on printing a warning if the codepage/LANG variable is set to something unusual, but does have the property of just swallowing problematic behavior. I'm fairly certain that will solve the major problems we have with GHC, and will fit the stack use case nicely. Does anyone else reading see a problem with this approach before I bring it up with the core libraries committee? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 10 05:54:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Aug 2015 05:54:46 -0000 Subject: [GHC] #8101: No pattern match non-exhaustiveness warnings when compiling with -fno-code In-Reply-To: <044.dfa43534fecae23d8d03f05e2e6d901b@haskell.org> References: <044.dfa43534fecae23d8d03f05e2e6d901b@haskell.org> Message-ID: <059.29add83df879cc0aaea0210df5d44aab@haskell.org> #8101: No pattern match non-exhaustiveness warnings when compiling with -fno-code -------------------------------------+------------------------------------- Reporter: exbb2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: T8101 Blocked By: | Blocking: Related Tickets: #10600 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => duplicate * related: => #10600 Comment: This was also recently reported in #10600, so closing in favor of that ticket. The fix here applied to one-shot mode (`-c`), but not make mode. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 10 07:04:13 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Aug 2015 07:04:13 -0000 Subject: [GHC] #10339: PatternSynonyms confuse exhaustiveness check In-Reply-To: <042.a1c90776a4d0c26d5af0fe09a172c987@haskell.org> References: <042.a1c90776a4d0c26d5af0fe09a172c987@haskell.org> Message-ID: <057.4bf412d93bdaee3da95ec90b3f2a476f@haskell.org> #10339: PatternSynonyms confuse exhaustiveness check -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 Resolution: duplicate | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8779 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by cactus): * status: new => closed * keywords: => PatternSynonyms * resolution: => duplicate * related: => #8779 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 10 07:06:13 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Aug 2015 07:06:13 -0000 Subject: [GHC] #10763: Failure to build GHC HEAD with 7.8 due to lint error Message-ID: <046.a6d2d6aadd5e702118d9d3dd2fe16e47@haskell.org> #10763: Failure to build GHC HEAD with 7.8 due to lint error -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I?m trying to build GHC HEAD, but it fails for me: {{{ ~/build/haskell/ghc $ make -j4 ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for 'phase_0_builds'. ===--- building phase 1 make --no-print-directory -f ghc.mk phase=1 phase_1_builds HC [stage 0] compiler/stage1/build/Coercion.o ghc: panic! (the 'impossible' happened) (GHC version 7.8.4 for x86_64-unknown-linux): Iface Lint failure In interface for ghc-7.11:CoAxiom Unfolding of ghc-7.11:CoAxiom.$fTypeableCoAxiom{v ryD} : Warning: [in an imported unfolding] Ill-kinded result in type or kind ?ghc-7.11:CoAxiom.BranchFlag{tc rgu} -> ghc-prim:GHC.Prim.*{(w) tc 34d}? type or kind ?ghc-7.11:CoAxiom.BranchFlag{tc rgu} -> ghc-prim:GHC.Prim.*{(w) tc 34d}? kind: ghc- prim:GHC.Prim.BOX{(w) tc 347} : Warning: [in an imported unfolding] Bad axiom application (check_ki2 ghc-prim:GHC.Prim.*{(w) tc 34d}>_N ghc-prim:GHC.Prim.*{(w) tc 34d} k{tv a8xP} [tv] ghc-prim:GHC.Prim.BOX{(w) tc 347}) base:Data.Typeable.Internal.NTCo:Typeable{tc r9X}[0] ghc-prim:GHC.Prim.*{(w) tc 34d}>_N _N ghc-7.11:CoAxiom.$fTypeableCoAxiom{v ryD} = ghc-7.11:CoAxiom.$fTypeableCoAxiom_$ctypeRep#{v rzw} [gid] `cast` (Sym (base:Data.Typeable.Internal.NTCo:Typeable{tc r9X}[0] ghc- prim:GHC.Prim.*{(w) tc 34d}>_N _N) :: (ghc- prim:GHC.Prim.Proxy#{(w) tc 38w} ghc-7.11:CoAxiom.CoAxiom{tc r6O} -> base:Data.Typeable.Internal.TypeRep{tc r9z}) ~# base:Data.Typeable.Internal.Typeable{tc 2k} ghc-7.11:CoAxiom.CoAxiom{tc r6O}) Iface expr = ghc-7.11:CoAxiom.$fTypeableCoAxiom_$ctypeRep#{v rzw} `cast` (Sym (base:Data.Typeable.Internal.NTCo:Typeable{tc r9X}[0] ghc-prim:GHC.Prim.*{(w) tc 34d}>_N _N)) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug compiler/ghc.mk:654: recipe for target 'compiler/stage1/build/Coercion.o' failed make[1]: *** [compiler/stage1/build/Coercion.o] Error 1 Makefile:103: recipe for target 'all' failed make: *** [all] Error 2 }}} Even if it turns out that this is a bug in 7.8 it would be nice to build HEAD out of the box with it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 10 07:07:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Aug 2015 07:07:34 -0000 Subject: [GHC] #10763: Failure to build GHC HEAD with 7.8 due to lint error In-Reply-To: <046.a6d2d6aadd5e702118d9d3dd2fe16e47@haskell.org> References: <046.a6d2d6aadd5e702118d9d3dd2fe16e47@haskell.org> Message-ID: <061.78a155e0b99574954bb8833a82714aa0@haskell.org> #10763: Failure to build GHC HEAD with 7.8 due to lint error -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Removing `-dcore-lint` from `GhcStage1HcOpts` allows the build to continue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 10 07:16:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Aug 2015 07:16:16 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms In-Reply-To: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> References: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> Message-ID: <061.19cd128eb16313628f1de6a16bc5c3c8@haskell.org> #8779: Exhaustiveness checks for pattern synonyms -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * version: 7.6.3 => 7.8.1 Comment: GHC 7.6 didn't support `PatternSynonyms` yet -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 10 07:25:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Aug 2015 07:25:27 -0000 Subject: [GHC] #10750: silly assembly for comparing Doubles In-Reply-To: <047.207ed991d667b8f8c95a3231e8362053@haskell.org> References: <047.207ed991d667b8f8c95a3231e8362053@haskell.org> Message-ID: <062.87b7aa18ee51aa58819de1c369604dd4@haskell.org> #10750: silly assembly for comparing Doubles -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10137, #10677 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => fixed Comment: > Maybe you built GHC's libraries at too low an optimization level? Heh, that?s it. I switched to `quickest` earlier to do a bisect, and did not switch back :-) Anyways, this produces a `ja` command now: {{{ _c36F: movsd 7(%rbx),%xmm0 xorpd %xmm1,%xmm1 ucomisd %xmm1,%xmm0 ja _c36U }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 10 11:05:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Aug 2015 11:05:31 -0000 Subject: [GHC] #10677: slightly silly assembly for testing whether a Word# is 0## In-Reply-To: <047.666ef36ac1cc91ac56611c092c7fbb22@haskell.org> References: <047.666ef36ac1cc91ac56611c092c7fbb22@haskell.org> Message-ID: <062.cac78f340032b2689d95bb8726b65a9a@haskell.org> #10677: slightly silly assembly for testing whether a Word# is 0## -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10750 | Differential Revisions: Phab:D1137 -------------------------------------+------------------------------------- Comment (by nomeata): This causes a `+ 15.08%` runtime regression in fannkuch-redux: https://perf.haskell.org/ghc/#graph/nofib/time/fannkuch- redux;hl=92f35cd9829db7555397aa3dc8cd243d17694fee This is a bit strange... is this just a possible reordering of basic blocks? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 10 13:04:28 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Aug 2015 13:04:28 -0000 Subject: [GHC] #10763: Failure to build GHC HEAD with 7.8 due to lint error In-Reply-To: <046.a6d2d6aadd5e702118d9d3dd2fe16e47@haskell.org> References: <046.a6d2d6aadd5e702118d9d3dd2fe16e47@haskell.org> Message-ID: <061.cdef2b0a9d59741f06aad5fe8edd72dd@haskell.org> #10763: Failure to build GHC HEAD with 7.8 due to lint error -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Are you sure you have a clean build? And what are your build settings? There ''was'' a recent change to `CoAxiom`, but of course this shouldn't happen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 10 13:54:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Aug 2015 13:54:45 -0000 Subject: [GHC] #8582: Record syntax for pattern synonyms In-Reply-To: <045.711f298e5aa28ce184df85985d614bd2@haskell.org> References: <045.711f298e5aa28ce184df85985d614bd2@haskell.org> Message-ID: <060.d7c6d239bcd7b99d49f2e3354c3c6daa@haskell.org> #8582: Record syntax for pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 5144 | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by mpickering): * owner: cactus => mpickering -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 10 14:24:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Aug 2015 14:24:46 -0000 Subject: [GHC] #10763: Failure to build GHC HEAD with 7.8 due to lint error In-Reply-To: <046.a6d2d6aadd5e702118d9d3dd2fe16e47@haskell.org> References: <046.a6d2d6aadd5e702118d9d3dd2fe16e47@haskell.org> Message-ID: <061.842e71244256e5b3e1b6d39c16334d66@haskell.org> #10763: Failure to build GHC HEAD with 7.8 due to lint error -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): I did run `make distclean`, but did not yet try with a fresh checkout. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 10 16:09:10 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Aug 2015 16:09:10 -0000 Subject: [GHC] #10763: Failure to build GHC HEAD with 7.8 due to lint error In-Reply-To: <046.a6d2d6aadd5e702118d9d3dd2fe16e47@haskell.org> References: <046.a6d2d6aadd5e702118d9d3dd2fe16e47@haskell.org> Message-ID: <061.071c352be2b65b41dc924fd5789ac895@haskell.org> #10763: Failure to build GHC HEAD with 7.8 due to lint error -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => wontfix Comment: I can reproduce. This indeed appears to be a bug in 7.8.4. But I'm not motivated to really get to the bottom of it. I think the correct behavior is to turn off `-dcore-lint`. It does seem to me that the bug is in the process of reading an iface file and setting kinds appropriately... although such a bad bug should have been more prominent. In any case, I think the current codebase for GHC is fine, so I'm closing this as wontfix, given that it relates to a no-longer-supported version of GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 10 19:04:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Aug 2015 19:04:49 -0000 Subject: [GHC] #8347: Add a Strict LANGUAGE pragma In-Reply-To: <044.d01bb368b2606104539d1aa05530b018@haskell.org> References: <044.d01bb368b2606104539d1aa05530b018@haskell.org> Message-ID: <059.f4b5d60d20d7bfba409b6580db97be79@haskell.org> #8347: Add a Strict LANGUAGE pragma -------------------------------------+------------------------------------- Reporter: tibbe | Owner: adamse Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: | Phab:D1033, Phab:D1142 -------------------------------------+------------------------------------- Changes (by adamse): * owner: tibbe => adamse * differential: Phab:D1033 => Phab:D1033, Phab:D1142 Old description: > A `Strict` `LANGUAGE` pragma would allow us to experiment with writing in > a strict sub-language. Since this pragma works on a per module basis, it > needs to be modular. I propose the following semantics: > > * Patterns are strict at the top-level, as if they had a top-level bang, > unless an explicit ~ is used to make the pattern lazy. > * Functions evaluate their parameters to WHNF. > * Data type fields are strict (as if they had a bang-pattern). New description: A `Strict` `LANGUAGE` pragma would allow us to experiment with writing in a strict sub-language. Since this pragma works on a per module basis, it needs to be modular. I propose the following semantics: * Patterns are strict at the top-level, as if they had a top-level bang, unless an explicit ~ is used to make the pattern lazy. * Functions evaluate their parameters to WHNF. * Data type fields are strict (as if they had a bang-pattern). Design page: StrictPragma -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 10 21:20:51 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Aug 2015 21:20:51 -0000 Subject: [GHC] #10742: GHC cannot deduce (irrelevant) reflexive type equality. In-Reply-To: <043.70009c4283c94391a26903bd5c00c1e8@haskell.org> References: <043.70009c4283c94391a26903bd5c00c1e8@haskell.org> Message-ID: <058.8db6aac8f4c7d08782a52566820db0ee@haskell.org> #10742: GHC cannot deduce (irrelevant) reflexive type equality. -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Keywords: TypeLits Resolution: fixed | GADTs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T10742 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ntc2): In case others run into this, here's a sketch of the workaround. Define a helper function to discharge the irrelevant constraint: {{{#!hs ghcBugWorkAround :: proxy m n -> ((m <=? n) ~ (m <=? n) => a) -> a ghcBugWorkAround _ x = x }}} Wrap the helper around the code which is causing the problem: {{{#!hs f (C ...) = -- Get "can't deduce `m <= n`" error here. }}} becomes {{{#!hs f (C ...) = ghcBugWorkAround $ }}} Note that this works even when `C ...` is a GADT pattern match which brings `m` or `n` into scope, in which case you can't simply change the type signature of `f` to include the `m <= n` constraint. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 10 23:29:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Aug 2015 23:29:25 -0000 Subject: [GHC] #10600: -fwarn-incomplete-patterns doesn't work with -fno-code In-Reply-To: <043.972d3170891da80a4e96bca7b675a836@haskell.org> References: <043.972d3170891da80a4e96bca7b675a836@haskell.org> Message-ID: <058.55aad93264bf535eea982a81fae98f63@haskell.org> #10600: -fwarn-incomplete-patterns doesn't work with -fno-code -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | driver/T8101b Blocked By: | Blocking: Related Tickets: #8101 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ntc2): This causes Emacs Flycheck to not warn for non-exhaustive patterns, because it runs GHC with `-fno-code`: https://github.com/flycheck/flycheck/issues/722. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 11 07:58:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Aug 2015 07:58:13 -0000 Subject: [GHC] #10764: GHC panic (no skolem info) Message-ID: <045.2ad1583af708dd0797f9fcecf7a4e2e8@haskell.org> #10764: GHC panic (no skolem info) -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The attached program causes GHC 7.10.2 to panic with the following output: bug.hs:6:19: Found hole ?_? with type: t1 ? t2 ? m1 a1 ? m1 a1 Where: ?t1? is a rigid type variable bound by the inferred type of whenMultipleOf ? MonadPlus m1 ? t1 ? t2 ? m1 a1 ? m1 a1 at bug.hs:7:1 ?a1? is a rigid type variable bound by the inferred type of whenMultipleOf ? MonadPlus m1 ? t1 ? t2 ? m1 a1 ? m1 a1 at bug.hs:7:1 ?m1? is a rigid type variable bound by the inferred type of whenMultipleOf ? MonadPlus m1 ? t1 ? t2 ? m1 a1 ? m1 a1 at bug.hs:7:1 ?t2? is a rigid type variable bound by the inferred type of whenMultipleOf ? MonadPlus m1 ? t1 ? t2 ? m1 a1 ? m1 a1 at bug.hs:7:1 To use the inferred type, enable PartialTypeSignatures In the type signature for ?whenMultipleOf?: _ bug.hs:7:1: No instance for (MonadPlus m) When checking that ?whenMultipleOf? has the specified type whenMultipleOf ? ? t a (m ? * ? *) t1. t ? t1 ? m a ? m a Probable cause: the inferred type is ambiguous bug.hs:10:62: Couldn't match type ?a1? with ?t? ?a1? is a rigid type variable bound by the type signature for sumOfMultiples ? Integral a1 ? [a1] ? a1 ? [a1] at bug.hs:9:19ghci-ng: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): No skolem info: t_a7vV[sk] 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 Tue Aug 11 07:59:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Aug 2015 07:59:13 -0000 Subject: [GHC] #10764: GHC panic (no skolem info) In-Reply-To: <045.2ad1583af708dd0797f9fcecf7a4e2e8@haskell.org> References: <045.2ad1583af708dd0797f9fcecf7a4e2e8@haskell.org> Message-ID: <060.94fcff00fb127cec2867c58a96b8d2f8@haskell.org> #10764: GHC panic (no skolem info) -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by zardoz): * Attachment "bug.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 11 08:27:37 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Aug 2015 08:27:37 -0000 Subject: [GHC] #10764: GHC panic (no skolem info) In-Reply-To: <045.2ad1583af708dd0797f9fcecf7a4e2e8@haskell.org> References: <045.2ad1583af708dd0797f9fcecf7a4e2e8@haskell.org> Message-ID: <060.3d13ff9b3ec1372ac30f7b5df007f932@haskell.org> #10764: GHC panic (no skolem info) -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * failure: None/Unknown => Compile-time crash Old description: > The attached program causes GHC 7.10.2 to panic with the following > output: > > bug.hs:6:19: > Found hole ?_? with type: t1 ? t2 ? m1 a1 ? m1 a1 > Where: ?t1? is a rigid type variable bound by > the inferred type of > whenMultipleOf ? MonadPlus m1 ? t1 ? t2 ? m1 a1 ? m1 a1 > at bug.hs:7:1 > ?a1? is a rigid type variable bound by > the inferred type of > whenMultipleOf ? MonadPlus m1 ? t1 ? t2 ? m1 a1 ? m1 a1 > at bug.hs:7:1 > ?m1? is a rigid type variable bound by > the inferred type of > whenMultipleOf ? MonadPlus m1 ? t1 ? t2 ? m1 a1 ? m1 a1 > at bug.hs:7:1 > ?t2? is a rigid type variable bound by > the inferred type of > whenMultipleOf ? MonadPlus m1 ? t1 ? t2 ? m1 a1 ? m1 a1 > at bug.hs:7:1 > To use the inferred type, enable PartialTypeSignatures > In the type signature for ?whenMultipleOf?: _ > > bug.hs:7:1: > No instance for (MonadPlus m) > When checking that ?whenMultipleOf? has the specified type > whenMultipleOf ? ? t a (m ? * ? *) t1. t ? t1 ? m a ? m a > Probable cause: the inferred type is ambiguous > > bug.hs:10:62: > Couldn't match type ?a1? with ?t? > ?a1? is a rigid type variable bound by > the type signature for > sumOfMultiples ? Integral a1 ? [a1] ? a1 ? [a1] > at bug.hs:9:19ghci-ng: panic! (the 'impossible' happened) > (GHC version 7.10.2 for x86_64-unknown-linux): > No skolem info: t_a7vV[sk] > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug New description: The attached program causes GHC 7.10.2 to panic with the following output: {{{ bug.hs:6:19: Found hole ?_? with type: t1 ? t2 ? m1 a1 ? m1 a1 Where: ?t1? is a rigid type variable bound by the inferred type of whenMultipleOf ? MonadPlus m1 ? t1 ? t2 ? m1 a1 ? m1 a1 at bug.hs:7:1 ?a1? is a rigid type variable bound by the inferred type of whenMultipleOf ? MonadPlus m1 ? t1 ? t2 ? m1 a1 ? m1 a1 at bug.hs:7:1 ?m1? is a rigid type variable bound by the inferred type of whenMultipleOf ? MonadPlus m1 ? t1 ? t2 ? m1 a1 ? m1 a1 at bug.hs:7:1 ?t2? is a rigid type variable bound by the inferred type of whenMultipleOf ? MonadPlus m1 ? t1 ? t2 ? m1 a1 ? m1 a1 at bug.hs:7:1 To use the inferred type, enable PartialTypeSignatures In the type signature for ?whenMultipleOf?: _ bug.hs:7:1: No instance for (MonadPlus m) When checking that ?whenMultipleOf? has the specified type whenMultipleOf ? ? t a (m ? * ? *) t1. t ? t1 ? m a ? m a Probable cause: the inferred type is ambiguous bug.hs:10:62: Couldn't match type ?a1? with ?t? ?a1? is a rigid type variable bound by the type signature for sumOfMultiples ? Integral a1 ? [a1] ? a1 ? [a1] at bug.hs:9:19ghci-ng: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): No skolem info: t_a7vV[sk] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Comment: Could you describe how you invoke GHC? I'm afraid I get no such error when I build your testcase with 7.10.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 11 10:04:23 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Aug 2015 10:04:23 -0000 Subject: [GHC] #10765: GHC panic: Loading temp shared object failed with `--enable-coverage` option Message-ID: <045.21dc250fb4eb23f768190337d56da937@haskell.org> #10765: GHC panic: Loading temp shared object failed with `--enable-coverage` option -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Code | Version: 7.10.1 Coverage | Keywords: hpc | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime crash (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Please see this StackOverflow question and answer for comprehensive description. http://stackoverflow.com/questions/31937302/ghc-panic-loading-temp-shared- object-failed In short, when test coverage (via HPC) is enabled (via `cabal configure --enable-coverage`) and `cabal repl` is started for non-test build target you get a GHC panic when you try to interact with your functions via REPL. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 11 10:38:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Aug 2015 10:38:41 -0000 Subject: [GHC] #10765: GHC panic: Loading temp shared object failed with `--enable-coverage` option In-Reply-To: <045.21dc250fb4eb23f768190337d56da937@haskell.org> References: <045.21dc250fb4eb23f768190337d56da937@haskell.org> Message-ID: <060.ef184329eb1bfc49100690ecb8c7dd3d@haskell.org> #10765: GHC panic: Loading temp shared object failed with `--enable-coverage` option -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Code Coverage | Version: 7.10.1 Resolution: | Keywords: hpc Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): To quote the ticket, {{{ ?> parseTest (string "rere" <* eof) "reri" ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc9380_0/libghc9380_93.so: undefined symbol: _hpc_tickboxes_megapzuEw3SHAmfXgNLpm5a31oXO6_TextziMegaparsecziError_hpc 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 Tue Aug 11 13:03:56 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Aug 2015 13:03:56 -0000 Subject: [GHC] #10760: Conflicting typefamily instances not reported with polykinds In-Reply-To: <045.f668c555ecaf923aed62f73fe3fd8413@haskell.org> References: <045.f668c555ecaf923aed62f73fe3fd8413@haskell.org> Message-ID: <060.00ba11d9c396784dc6528e4395bfc668@haskell.org> #10760: Conflicting typefamily instances not reported with polykinds -------------------------------------+------------------------------------- Reporter: steely | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"2da06d7c3fb0da894f5b5a6770c4e41aeee012cd/ghc" 2da06d7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2da06d7c3fb0da894f5b5a6770c4e41aeee012cd" User manual update, as prodded by #10760. This clarifies that kind variables are inputs to type families and can be used to distinguish instances. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 11 13:04:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Aug 2015 13:04:30 -0000 Subject: [GHC] #10760: Conflicting typefamily instances not reported with polykinds In-Reply-To: <045.f668c555ecaf923aed62f73fe3fd8413@haskell.org> References: <045.f668c555ecaf923aed62f73fe3fd8413@haskell.org> Message-ID: <060.c9267db8d294b258e84b1241a82cc615@haskell.org> #10760: Conflicting typefamily instances not reported with polykinds -------------------------------------+------------------------------------- Reporter: steely | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Thanks for the suggestion! I've put that in. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 11 13:11:23 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Aug 2015 13:11:23 -0000 Subject: [GHC] #10765: GHC panic: Loading temp shared object failed with `--enable-coverage` option In-Reply-To: <045.21dc250fb4eb23f768190337d56da937@haskell.org> References: <045.21dc250fb4eb23f768190337d56da937@haskell.org> Message-ID: <060.09bd6528371fba812e4d3c14ffccd250@haskell.org> #10765: GHC panic: Loading temp shared object failed with `--enable-coverage` option -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Code Coverage | Version: 7.10.1 Resolution: | Keywords: hpc Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Yuras): I saw the same issue too, but it is `cabal` fault because it passes `-fhpc` to `ghci`. Note: `cabal exec ghci` works, but `cabal exec ghci -- -fhpc` fails. Lack of HPC support in interpreter is [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/hpc.html#idp22264416 documented]. The relevant issue about bad error message from ghc is #9903. I propose to open an issue on `cabal`s tracker and close this one as a duplicate of #9903. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 11 13:22:55 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Aug 2015 13:22:55 -0000 Subject: [GHC] #10765: GHC panic: Loading temp shared object failed with `--enable-coverage` option In-Reply-To: <045.21dc250fb4eb23f768190337d56da937@haskell.org> References: <045.21dc250fb4eb23f768190337d56da937@haskell.org> Message-ID: <060.f40ced2291689a7223acbcb5041ee334@haskell.org> #10765: GHC panic: Loading temp shared object failed with `--enable-coverage` option -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Code Coverage | Version: 7.10.1 Resolution: | Keywords: hpc Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by mrkkrp): Replying to [comment:2 Yuras]: > I saw the same issue too, but it is `cabal` fault because it passes `-fhpc` to `ghci`. Note: `cabal exec ghci` works, but `cabal exec ghci -- -fhpc` fails. > > Lack of HPC support in interpreter is [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/hpc.html#idp22264416 documented]. The relevant issue about bad error message from ghc is #9903. > > I propose to open an issue on `cabal`s tracker and close this one as a duplicate of #9903. I opened an issue on Cabal's GitHub page before reporting it here: https://github.com/haskell/cabal/issues/2757 where I was told that "GHC Panic" is usually signifies a GHC bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 11 15:46:59 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Aug 2015 15:46:59 -0000 Subject: [GHC] #10765: GHC panic: Loading temp shared object failed with `--enable-coverage` option In-Reply-To: <045.21dc250fb4eb23f768190337d56da937@haskell.org> References: <045.21dc250fb4eb23f768190337d56da937@haskell.org> Message-ID: <060.d9c6b54757e0734bcc4e38136dc7a9fa@haskell.org> #10765: GHC panic: Loading temp shared object failed with `--enable-coverage` option -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Code Coverage | Version: 7.10.1 Resolution: duplicate | Keywords: hpc Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9903 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by Yuras): * status: new => closed * resolution: => duplicate * os: Linux => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple * related: => #9903 Comment: Replying to [comment:3 mrkkrp]: > I opened an issue on Cabal's GitHub page before reporting it here: > > https://github.com/haskell/cabal/issues/2757 > > where I was told that "GHC Panic" is usually signifies a GHC bug. They are right, ghc should fail with polite error message instead of a panic, but that is exactly why #9903 exists. Cabal's fault is to pass `-fhpc` to `ghci`. I sent a fix to Cabal, so closing. Thank you for reporting the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 11 18:37:18 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Aug 2015 18:37:18 -0000 Subject: [GHC] #10672: checkProddableBlock crash during Template Haskell linking In-Reply-To: <045.04cee7c60b130b0ccc29791ed61c4f5f@haskell.org> References: <045.04cee7c60b130b0ccc29791ed61c4f5f@haskell.org> Message-ID: <060.3470bfc36fe67d0db1db7a3f9207fd72@haskell.org> #10672: checkProddableBlock crash during Template Haskell linking -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #9297 #10563 | Differential Revisions: #8237 #9907 | -------------------------------------+------------------------------------- Changes (by Phyx-): * cc: Phyx- (added) Comment: Hmm, this seems to happen because in `checkProddableBlock` the `oc->proddables` is NULL. So it has no blocks to check and it errors out. Don't know why it errors out and doesn't skip that ObjectCode and continue when there are no `proddables`. I'm pretty new at the linker so hopefully someone who knows more about this part can explain it. Also it won't work on anything prior to 7.10.x since you'll get the Unknown PE section error fixed in #9907 I don't think #9297 is related either, which seems to have more to do with the name manglings. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 11 18:40:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Aug 2015 18:40:40 -0000 Subject: [GHC] #10766: user manual: INLINE's interaction with optimization levels is not clear Message-ID: <043.95e7d1c8fa07ad8573df841b0fc2eccf@haskell.org> #10766: user manual: INLINE's interaction with optimization levels is not clear -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: task | Status: new Priority: normal | Milestone: Component: | Version: 7.11 Documentation | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- user manual: INLINE's interaction with optimization levels is not clear From the user manual it's not possible to say how should INLINE and actual inlining behavior should interact with optimization levels. What the user manuals says: - Without INLINE GHC tries to inline depending on size of definitions and current optimization level(user manual says -O is needed, but can we assume that for any inlining to be done we need at least -O? Because I have an example in which inlining is happening even with -O0). - With INLINE GHC tries hard to inline. But it doesn't say which optimization level is needed. I think we should add word or two about this. Does anyone know the answer here? My guess is: Even though INLINE makes sure GHC saves RHS of the definition in .hi files to be able to inline later, optimization levels still have an effect on deciding whether to inline or not. Because some INLINEd RHSs may be too big in which case it may decide not to inline with -O1 but inline with -O2 etc. Furthermore, without -O, GHC doesn't mark definitions as INLINE. But if we have INLINEd definitions and compiling a code with -O0, it may still inline those definitions, because there are two different mechanisms to decide whether to mark as INLINE and whether to inline the RHS, and while without -O GHC doesn't mark anything as INLINE, it can still inline previously marked definitions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 11 18:40:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Aug 2015 18:40:50 -0000 Subject: [GHC] #10766: user manual: INLINE's interaction with optimization levels is not clear In-Reply-To: <043.95e7d1c8fa07ad8573df841b0fc2eccf@haskell.org> References: <043.95e7d1c8fa07ad8573df841b0fc2eccf@haskell.org> Message-ID: <058.a67d207d0a627dd24b6629e12d9cc325@haskell.org> #10766: user manual: INLINE's interaction with optimization levels is not clear -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by osa1: Old description: > user manual: INLINE's interaction with optimization levels is not clear > > From the user manual it's not possible to say how should INLINE and > actual inlining behavior should interact with optimization levels. > > What the user manuals says: > > - Without INLINE GHC tries to inline depending on size of definitions and > current optimization level(user manual says -O is needed, but can we > assume that for any inlining to be done we need at least -O? Because I > have an example in which inlining is happening even with -O0). > > - With INLINE GHC tries hard to inline. But it doesn't say which > optimization level is needed. > > I think we should add word or two about this. Does anyone know the answer > here? > > My guess is: Even though INLINE makes sure GHC saves RHS of the > definition in .hi files to be able to inline later, optimization levels > still have an effect on deciding whether to inline or not. Because some > INLINEd RHSs may be too big in which case it may decide not to inline > with -O1 but inline with -O2 etc. > > Furthermore, without -O, GHC doesn't mark definitions as INLINE. But if > we have INLINEd definitions and compiling a code with -O0, it may still > inline those definitions, because there are two different mechanisms to > decide whether to mark as INLINE and whether to inline the RHS, and while > without -O GHC doesn't mark anything as INLINE, it can still inline > previously marked definitions. New description: From the user manual it's not possible to say how should INLINE and actual inlining behavior should interact with optimization levels. What the user manuals says: - Without INLINE GHC tries to inline depending on size of definitions and current optimization level(user manual says -O is needed, but can we assume that for any inlining to be done we need at least -O? Because I have an example in which inlining is happening even with -O0). - With INLINE GHC tries hard to inline. But it doesn't say which optimization level is needed. I think we should add word or two about this. Does anyone know the answer here? My guess is: Even though INLINE makes sure GHC saves RHS of the definition in .hi files to be able to inline later, optimization levels still have an effect on deciding whether to inline or not. Because some INLINEd RHSs may be too big in which case it may decide not to inline with -O1 but inline with -O2 etc. Furthermore, without -O, GHC doesn't mark definitions as INLINE. But if we have INLINEd definitions and compiling a code with -O0, it may still inline those definitions, because there are two different mechanisms to decide whether to mark as INLINE and whether to inline the RHS, and while without -O GHC doesn't mark anything as INLINE, it can still inline previously marked definitions. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 11 19:05:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Aug 2015 19:05:25 -0000 Subject: [GHC] #10767: SPECIALIZE generates warning but works fine Message-ID: <043.4ebd25de1b3c74f2b23206d88f108b5f@haskell.org> #10767: SPECIALIZE generates warning but works fine -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I have this code: {{{#!hs {-# LANGUAGE ScopedTypeVariables, TypeFamilies #-} module Main where import Data.Proxy class SpecList a where type List a :: * slCase :: List a -> b -> (a -> List a -> b) -> b data IntList = ILNil | ILCons {-# UNPACK #-} !Int IntList deriving (Show) instance SpecList Int where type List Int = IntList slCase ILNil n _ = n slCase (ILCons i t) _ c = c i t fromList :: [Int] -> IntList fromList [] = ILNil fromList (h : t) = ILCons h (fromList t) lst1 :: IntList lst1 = fromList [1..10] {-# SPECIALIZE genLength :: Proxy Int -> List Int -> Int #-} genLength :: forall a . SpecList a => Proxy a -> List a -> Int genLength p lst = slCase lst 0 (\(_ :: a) tail -> 1 + genLength p tail) main :: IO () main = print (genLength (Proxy :: Proxy Int) lst1) }}} When I compile it(no matter which optimization level is used), it prints this warning: {{{ Main.hs:30:1: Warning: RULE left-hand side too complicated to desugar Optimised lhs: case cobox_a17r of _ [Occ=Dead] { GHC.Types.Eq# cobox -> genLength @ Int $dSpecList_a17q } Orig lhs: case cobox_a17r of cobox_a17r { GHC.Types.Eq# cobox -> genLength @ Int $dSpecList_a17q } }}} (I presume this is related with the rewrite rule generated to be able to replace calls to generic version to calls to specialized versions when possible.) But this program compiles fine with -O2, i.e. `genLength lst1` is replaced with specialized definition of `genLength`, without any dictionary passing. So the warning is confusing for two reasons: - It's not related with the code, it seems like it's a problem with GHC- generated rewrite rule. - It still works fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 11 22:37:19 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Aug 2015 22:37:19 -0000 Subject: [GHC] #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` In-Reply-To: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> References: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> Message-ID: <060.5a4657860b40401183f63325dc44c335@haskell.org> #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1062, #1176, | Differential Revisions: #7666, #8809 | Phab:D1130, Phab:D1132 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: Phab:D1130 => Phab:D1130, Phab:D1132 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 11 23:19:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Aug 2015 23:19:41 -0000 Subject: [GHC] #9143: feature request: way to set actual program argv In-Reply-To: <047.14769c1c2bab59d46b7097edaaa12dc6@haskell.org> References: <047.14769c1c2bab59d46b7097edaaa12dc6@haskell.org> Message-ID: <062.495125733fdf9dad0e20b2fe012bf090@haskell.org> #9143: feature request: way to set actual program argv -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by joeyhess): This stackoverflow answer gives a way to do it without ghc changes and without needing unusual linker options: http://stackoverflow.com/questions/26657699/how-to-change-the-name-of-a -haskell-process-under-linux Still, that seems quite a hack, maybe linux/glibc-specific also? I continue to feel that, since changing the name displayed by ps for a program is easy to accomplish in most any other language, and many unix programs use the ability to do so, it should also be made reasonably easy to do in haskell. Often, a program will want to change argv[0] but not the thread name. For example, ssh will set the argv[0] to various things like "sshd: joey" but leaves the thread name "sshd". So, an interface to prctl should be kept separate from an interface to argv[0]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 09:23:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 09:23:08 -0000 Subject: [GHC] #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` In-Reply-To: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> References: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> Message-ID: <060.63d6288d08d9777394e7a618d6bd404e@haskell.org> #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1062, #1176, | Differential Revisions: #7666, #8809 | Phab:D1130, Phab:D1132 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"67576ddc67f39bef43c473f30af0887d22011710/ghc" 67576ddc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="67576ddc67f39bef43c473f30af0887d22011710" Pretty: bugfix fillNB (#10735) This is a backport of a bug fix by Benedikt Huber (#2393), from commit 1e50748beaa4bd2281d323b18ea51c786bba04a1 in the pretty library. From https://mail.haskell.org/pipermail/libraries/2008-June/009991.html: Law states that > sep (ps++[empty]++qs) = sep (ps ++ qs) > ...ditto hsep, hcat, vcat, fill... In the current implementation, this fails for the paragraph fill variants. > render' $ fsep [ text "c", text "c",empty, text "c", text "b"] > where render' = renderStyle (Style PageMode 7 1.4) >> c c c >> b }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 09:23:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 09:23:08 -0000 Subject: [GHC] #2393: Text.PrettyPrint.HughesPJ: Bug fixes, performance improvement In-Reply-To: <044.a2eb2249d4c87d53c08ed2cb37607972@haskell.org> References: <044.a2eb2249d4c87d53c08ed2cb37607972@haskell.org> Message-ID: <059.d6a8391166e88ba52382976903cf0baa@haskell.org> #2393: Text.PrettyPrint.HughesPJ: Bug fixes, performance improvement -------------------------------------+--------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: libraries/pretty | Version: 6.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Test Case: | -------------------------------------+--------------------------------- Comment (by Thomas Miedema ): In [changeset:"67576ddc67f39bef43c473f30af0887d22011710/ghc" 67576ddc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="67576ddc67f39bef43c473f30af0887d22011710" Pretty: bugfix fillNB (#10735) This is a backport of a bug fix by Benedikt Huber (#2393), from commit 1e50748beaa4bd2281d323b18ea51c786bba04a1 in the pretty library. From https://mail.haskell.org/pipermail/libraries/2008-June/009991.html: Law states that > sep (ps++[empty]++qs) = sep (ps ++ qs) > ...ditto hsep, hcat, vcat, fill... In the current implementation, this fails for the paragraph fill variants. > render' $ fsep [ text "c", text "c",empty, text "c", text "b"] > where render' = renderStyle (Style PageMode 7 1.4) >> c c c >> b }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 09:23:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 09:23:08 -0000 Subject: [GHC] #1337: Fix wrong indentation from Text.PrettyPrint.HughesPJ fill (fcat and fsep) In-Reply-To: <050.0d1c36f5d6cac580edd71d8a018225c6@haskell.org> References: <050.0d1c36f5d6cac580edd71d8a018225c6@haskell.org> Message-ID: <065.7e53b24bf031ddf1efefb3013eb61c80@haskell.org> #1337: Fix wrong indentation from Text.PrettyPrint.HughesPJ fill (fcat and fsep) -------------------------------------+--------------------------------- Reporter: thorkilnaur | Owner: thorkilnaur Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: libraries/pretty | Version: 6.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Test Case: Pp003 | -------------------------------------+--------------------------------- Comment (by Thomas Miedema ): In [changeset:"bcfae08c0be0fa8604e2025733dfae57e37c2083/ghc" bcfae08c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bcfae08c0be0fa8604e2025733dfae57e37c2083" Pretty: fix potential bad formatting of error message (#10735) This is a backport of a bug fix by Benedikt Huber for the same problem in the pretty library (#1337), from commit 8d8866a8379c2fe8108ef034893c59e06d5e752f. The original explanation for the fix is attached below. Ticket #1776 originally reported an infinite loop when printing error message. This promptly got fixed in: commit 2d52ee06786e5caf0c2d65a4b4bb7c45c6493190 Author: simonpj at microsoft.com Date: Thu Mar 1 11:45:13 2007 +0000 Do not go into an infinite loop when pretty-printer finds a negative indent (Trac #1176) SPJ reports in the ticket: "So infinite loop is fixed, but the bad formatting remains. I've added a test, tcfail177." tcfail177 however hasn't triggered the formatting problem for years (as Ian reported in c9e0e6067a47c574d9ff3721afe58e30ca1be3e4). This patch updates the test to a version that at least still failed with ghc-7.0 (from #1776#comment:7). ------------------- From https://mail.haskell.org/pipermail/libraries/2008-June/010013.html, by Benedikt Huber: Concerning ticket #1337, we have to change the formal specification of fill (it doesn't match the implementation): -- Current Specification: -- fill [] = empty -- fill [p] = p -- fill (p1:p2:ps) = oneLiner p1 <#> nest (length p1) -- (fill (oneLiner p2 : ps)) -- `union` -- p1 $$ fill ps Problem 1: We want to `unnest' the second argument of (p1 $$ fill ps), but not the first one In the definition above we have e.g. > getSecondLayout $ > fillDef False [text "a", text "b", text "a"] >> text "ab"; nilabove; nest -1; text "a"; empty >> |ab| >> |.a| Problem 2: The overlapping $$ should only be used for those layouts of p1 which aren't one liners (otherwise violating the invariant "Left union arg has shorter first line"). I suggest the following specification (i believe it almost matches the current implementation, modulo [fillNB: fix bug #1337] (see below): -- Revised Specification: -- fill g docs = fill' 0 docs -- gap g = if g then 1 else 0 -- fill' n [] = [] -- fill' n [p] = [p] -- fill' n (p1:p2:ps) = -- oneLiner p1 (fill' (n+length p1+gap g) (oneLiner p2 : ps)) -- `union` -- (p1 $*$ nest (-n) (fill' g ps)) -- -- $*$ is defined for layouts (One-Layout Documents) as -- -- layout1 $*$ layout2 | isOneLiner layout1 = layout1 $+$ layout2 -- | otherwise = layout1 $$ layout2 I've also implemented the specification in HughesPJQuickCheck.hs, and checked them against the patched pretty printer. Concerning Bug #1337: ~~~~~~~~~~~~~~~~~~~~~ If the above formal specification is fine, it is easy to fix: elide the nests of (oneLiner p2) [see attached patch, record bug #1337]. > PrettyPrint(0) $ ./Bug1337 > ....ab > ...c The (long) explanation follows below. =========================================================== Explanation of Bug #1337: Consider > fcat [ nest 1 $ text "a", nest 2 $ text "b", text "c"] --> expected: (nest 1; text "a"; text "b"; nest -3; "c") --> actual : (nest 1; text "a"; text "b"; nest -5; "c") Reduction: === (nest 1; text a) <> (fill (-2) (p2:ps)) ==> (nest 2 (text "b") $+$ text "c") ==> (nest 2 (text "b")) `nilabove` (nest (-3) (text "c")) ==> (nest 1; text a; text b; nest -5 c) The problem is that if we decide to layout (p1:p2:ps) as | p1 p2 | ps (call it layout A), then we want to have > (p1 <> p2) $+$ ps. But following law this means that > fcat_A [p1:nest k p2:ps] is equivalent to > fcat_A [p1,p2,ps] so the nest of p2 has to be removed. This is somewhat similar to bug #667, but easier to fix from a semantic point of view: p1,p2 and ps are distinct layouts - we only have to preserve the individual layouts, and no combinations of them. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 09:23:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 09:23:08 -0000 Subject: [GHC] #1776: type families : couldn't match type "Elem a" against type "Elem a" In-Reply-To: <044.4a6ff2b352cb037a5d1ac3a7261867d6@haskell.org> References: <044.4a6ff2b352cb037a5d1ac3a7261867d6@haskell.org> Message-ID: <059.34252a1449171cdf714269ccc1cc9f05@haskell.org> #1776: type families : couldn't match type "Elem a" against type "Elem a" -------------------------------------+--------------------------------- Reporter: guest | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Test Case: | -------------------------------------+--------------------------------- Comment (by Thomas Miedema ): In [changeset:"bcfae08c0be0fa8604e2025733dfae57e37c2083/ghc" bcfae08c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bcfae08c0be0fa8604e2025733dfae57e37c2083" Pretty: fix potential bad formatting of error message (#10735) This is a backport of a bug fix by Benedikt Huber for the same problem in the pretty library (#1337), from commit 8d8866a8379c2fe8108ef034893c59e06d5e752f. The original explanation for the fix is attached below. Ticket #1776 originally reported an infinite loop when printing error message. This promptly got fixed in: commit 2d52ee06786e5caf0c2d65a4b4bb7c45c6493190 Author: simonpj at microsoft.com Date: Thu Mar 1 11:45:13 2007 +0000 Do not go into an infinite loop when pretty-printer finds a negative indent (Trac #1176) SPJ reports in the ticket: "So infinite loop is fixed, but the bad formatting remains. I've added a test, tcfail177." tcfail177 however hasn't triggered the formatting problem for years (as Ian reported in c9e0e6067a47c574d9ff3721afe58e30ca1be3e4). This patch updates the test to a version that at least still failed with ghc-7.0 (from #1776#comment:7). ------------------- From https://mail.haskell.org/pipermail/libraries/2008-June/010013.html, by Benedikt Huber: Concerning ticket #1337, we have to change the formal specification of fill (it doesn't match the implementation): -- Current Specification: -- fill [] = empty -- fill [p] = p -- fill (p1:p2:ps) = oneLiner p1 <#> nest (length p1) -- (fill (oneLiner p2 : ps)) -- `union` -- p1 $$ fill ps Problem 1: We want to `unnest' the second argument of (p1 $$ fill ps), but not the first one In the definition above we have e.g. > getSecondLayout $ > fillDef False [text "a", text "b", text "a"] >> text "ab"; nilabove; nest -1; text "a"; empty >> |ab| >> |.a| Problem 2: The overlapping $$ should only be used for those layouts of p1 which aren't one liners (otherwise violating the invariant "Left union arg has shorter first line"). I suggest the following specification (i believe it almost matches the current implementation, modulo [fillNB: fix bug #1337] (see below): -- Revised Specification: -- fill g docs = fill' 0 docs -- gap g = if g then 1 else 0 -- fill' n [] = [] -- fill' n [p] = [p] -- fill' n (p1:p2:ps) = -- oneLiner p1 (fill' (n+length p1+gap g) (oneLiner p2 : ps)) -- `union` -- (p1 $*$ nest (-n) (fill' g ps)) -- -- $*$ is defined for layouts (One-Layout Documents) as -- -- layout1 $*$ layout2 | isOneLiner layout1 = layout1 $+$ layout2 -- | otherwise = layout1 $$ layout2 I've also implemented the specification in HughesPJQuickCheck.hs, and checked them against the patched pretty printer. Concerning Bug #1337: ~~~~~~~~~~~~~~~~~~~~~ If the above formal specification is fine, it is easy to fix: elide the nests of (oneLiner p2) [see attached patch, record bug #1337]. > PrettyPrint(0) $ ./Bug1337 > ....ab > ...c The (long) explanation follows below. =========================================================== Explanation of Bug #1337: Consider > fcat [ nest 1 $ text "a", nest 2 $ text "b", text "c"] --> expected: (nest 1; text "a"; text "b"; nest -3; "c") --> actual : (nest 1; text "a"; text "b"; nest -5; "c") Reduction: === (nest 1; text a) <> (fill (-2) (p2:ps)) ==> (nest 2 (text "b") $+$ text "c") ==> (nest 2 (text "b")) `nilabove` (nest (-3) (text "c")) ==> (nest 1; text a; text b; nest -5 c) The problem is that if we decide to layout (p1:p2:ps) as | p1 p2 | ps (call it layout A), then we want to have > (p1 <> p2) $+$ ps. But following law this means that > fcat_A [p1:nest k p2:ps] is equivalent to > fcat_A [p1,p2,ps] so the nest of p2 has to be removed. This is somewhat similar to bug #667, but easier to fix from a semantic point of view: p1,p2 and ps are distinct layouts - we only have to preserve the individual layouts, and no combinations of them. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 09:23:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 09:23:08 -0000 Subject: [GHC] #1176: Infinite loop when printing error message In-Reply-To: <064.2f219b840bdf4c0010ac5cb2a55fa8db@haskell.org> References: <064.2f219b840bdf4c0010ac5cb2a55fa8db@haskell.org> Message-ID: <079.20514d16600518848a6ac6efed810ad8@haskell.org> #1176: Infinite loop when printing error message -------------------------------------+--------------------------------- Reporter: Paul_Berry@? | Owner: thorkilnaur Type: bug | Status: new Priority: low | Milestone: ? Component: Compiler | Version: 6.6 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: tcfail177 Blocked By: | Blocking: Related Tickets: | -------------------------------------+--------------------------------- Comment (by Thomas Miedema ): In [changeset:"bcfae08c0be0fa8604e2025733dfae57e37c2083/ghc" bcfae08c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bcfae08c0be0fa8604e2025733dfae57e37c2083" Pretty: fix potential bad formatting of error message (#10735) This is a backport of a bug fix by Benedikt Huber for the same problem in the pretty library (#1337), from commit 8d8866a8379c2fe8108ef034893c59e06d5e752f. The original explanation for the fix is attached below. Ticket #1776 originally reported an infinite loop when printing error message. This promptly got fixed in: commit 2d52ee06786e5caf0c2d65a4b4bb7c45c6493190 Author: simonpj at microsoft.com Date: Thu Mar 1 11:45:13 2007 +0000 Do not go into an infinite loop when pretty-printer finds a negative indent (Trac #1176) SPJ reports in the ticket: "So infinite loop is fixed, but the bad formatting remains. I've added a test, tcfail177." tcfail177 however hasn't triggered the formatting problem for years (as Ian reported in c9e0e6067a47c574d9ff3721afe58e30ca1be3e4). This patch updates the test to a version that at least still failed with ghc-7.0 (from #1776#comment:7). ------------------- From https://mail.haskell.org/pipermail/libraries/2008-June/010013.html, by Benedikt Huber: Concerning ticket #1337, we have to change the formal specification of fill (it doesn't match the implementation): -- Current Specification: -- fill [] = empty -- fill [p] = p -- fill (p1:p2:ps) = oneLiner p1 <#> nest (length p1) -- (fill (oneLiner p2 : ps)) -- `union` -- p1 $$ fill ps Problem 1: We want to `unnest' the second argument of (p1 $$ fill ps), but not the first one In the definition above we have e.g. > getSecondLayout $ > fillDef False [text "a", text "b", text "a"] >> text "ab"; nilabove; nest -1; text "a"; empty >> |ab| >> |.a| Problem 2: The overlapping $$ should only be used for those layouts of p1 which aren't one liners (otherwise violating the invariant "Left union arg has shorter first line"). I suggest the following specification (i believe it almost matches the current implementation, modulo [fillNB: fix bug #1337] (see below): -- Revised Specification: -- fill g docs = fill' 0 docs -- gap g = if g then 1 else 0 -- fill' n [] = [] -- fill' n [p] = [p] -- fill' n (p1:p2:ps) = -- oneLiner p1 (fill' (n+length p1+gap g) (oneLiner p2 : ps)) -- `union` -- (p1 $*$ nest (-n) (fill' g ps)) -- -- $*$ is defined for layouts (One-Layout Documents) as -- -- layout1 $*$ layout2 | isOneLiner layout1 = layout1 $+$ layout2 -- | otherwise = layout1 $$ layout2 I've also implemented the specification in HughesPJQuickCheck.hs, and checked them against the patched pretty printer. Concerning Bug #1337: ~~~~~~~~~~~~~~~~~~~~~ If the above formal specification is fine, it is easy to fix: elide the nests of (oneLiner p2) [see attached patch, record bug #1337]. > PrettyPrint(0) $ ./Bug1337 > ....ab > ...c The (long) explanation follows below. =========================================================== Explanation of Bug #1337: Consider > fcat [ nest 1 $ text "a", nest 2 $ text "b", text "c"] --> expected: (nest 1; text "a"; text "b"; nest -3; "c") --> actual : (nest 1; text "a"; text "b"; nest -5; "c") Reduction: === (nest 1; text a) <> (fill (-2) (p2:ps)) ==> (nest 2 (text "b") $+$ text "c") ==> (nest 2 (text "b")) `nilabove` (nest (-3) (text "c")) ==> (nest 1; text a; text b; nest -5 c) The problem is that if we decide to layout (p1:p2:ps) as | p1 p2 | ps (call it layout A), then we want to have > (p1 <> p2) $+$ ps. But following law this means that > fcat_A [p1:nest k p2:ps] is equivalent to > fcat_A [p1,p2,ps] so the nest of p2 has to be removed. This is somewhat similar to bug #667, but easier to fix from a semantic point of view: p1,p2 and ps are distinct layouts - we only have to preserve the individual layouts, and no combinations of them. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 09:23:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 09:23:08 -0000 Subject: [GHC] #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` In-Reply-To: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> References: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> Message-ID: <060.96cdb66b4fe7525917dcdbef61acf1de@haskell.org> #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1062, #1176, | Differential Revisions: #7666, #8809 | Phab:D1130, Phab:D1132 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"5d57087e314bd484dbe14958f9b422be3ac6641a/ghc" 5d57087/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5d57087e314bd484dbe14958f9b422be3ac6641a" Pretty: fix a broken invariant (#10735) This is a backport of a bug fix from 6cfbd0444981c074bae10a3cf72733bcb8597bef in libraries/pretty: Fix a broken invariant Patch from #694, for the problem "empty is an identity for <> and $$" is currently broken by eg. isEmpty (empty<>empty)" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 09:23:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 09:23:08 -0000 Subject: [GHC] #694: lawbreaker in HughesPJ In-Reply-To: <052.90fdf924b5fd84e7efbaf36c9036a5a3@haskell.org> References: <052.90fdf924b5fd84e7efbaf36c9036a5a3@haskell.org> Message-ID: <067.78e12c29ea3ed170d36f9eb6750e3db5@haskell.org> #694: lawbreaker in HughesPJ -------------------------------------+--------------------------------- Reporter: maeder@? | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.4.2 Component: libraries/base | Version: 6.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------------+--------------------------------- Comment (by Thomas Miedema ): In [changeset:"5d57087e314bd484dbe14958f9b422be3ac6641a/ghc" 5d57087/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5d57087e314bd484dbe14958f9b422be3ac6641a" Pretty: fix a broken invariant (#10735) This is a backport of a bug fix from 6cfbd0444981c074bae10a3cf72733bcb8597bef in libraries/pretty: Fix a broken invariant Patch from #694, for the problem "empty is an identity for <> and $$" is currently broken by eg. isEmpty (empty<>empty)" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 09:23:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 09:23:08 -0000 Subject: [GHC] #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` In-Reply-To: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> References: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> Message-ID: <060.1050058274ad43dd74487804d7df99f4@haskell.org> #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1062, #1176, | Differential Revisions: #7666, #8809 | Phab:D1130, Phab:D1132 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"bcfae08c0be0fa8604e2025733dfae57e37c2083/ghc" bcfae08c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bcfae08c0be0fa8604e2025733dfae57e37c2083" Pretty: fix potential bad formatting of error message (#10735) This is a backport of a bug fix by Benedikt Huber for the same problem in the pretty library (#1337), from commit 8d8866a8379c2fe8108ef034893c59e06d5e752f. The original explanation for the fix is attached below. Ticket #1776 originally reported an infinite loop when printing error message. This promptly got fixed in: commit 2d52ee06786e5caf0c2d65a4b4bb7c45c6493190 Author: simonpj at microsoft.com Date: Thu Mar 1 11:45:13 2007 +0000 Do not go into an infinite loop when pretty-printer finds a negative indent (Trac #1176) SPJ reports in the ticket: "So infinite loop is fixed, but the bad formatting remains. I've added a test, tcfail177." tcfail177 however hasn't triggered the formatting problem for years (as Ian reported in c9e0e6067a47c574d9ff3721afe58e30ca1be3e4). This patch updates the test to a version that at least still failed with ghc-7.0 (from #1776#comment:7). ------------------- From https://mail.haskell.org/pipermail/libraries/2008-June/010013.html, by Benedikt Huber: Concerning ticket #1337, we have to change the formal specification of fill (it doesn't match the implementation): -- Current Specification: -- fill [] = empty -- fill [p] = p -- fill (p1:p2:ps) = oneLiner p1 <#> nest (length p1) -- (fill (oneLiner p2 : ps)) -- `union` -- p1 $$ fill ps Problem 1: We want to `unnest' the second argument of (p1 $$ fill ps), but not the first one In the definition above we have e.g. > getSecondLayout $ > fillDef False [text "a", text "b", text "a"] >> text "ab"; nilabove; nest -1; text "a"; empty >> |ab| >> |.a| Problem 2: The overlapping $$ should only be used for those layouts of p1 which aren't one liners (otherwise violating the invariant "Left union arg has shorter first line"). I suggest the following specification (i believe it almost matches the current implementation, modulo [fillNB: fix bug #1337] (see below): -- Revised Specification: -- fill g docs = fill' 0 docs -- gap g = if g then 1 else 0 -- fill' n [] = [] -- fill' n [p] = [p] -- fill' n (p1:p2:ps) = -- oneLiner p1 (fill' (n+length p1+gap g) (oneLiner p2 : ps)) -- `union` -- (p1 $*$ nest (-n) (fill' g ps)) -- -- $*$ is defined for layouts (One-Layout Documents) as -- -- layout1 $*$ layout2 | isOneLiner layout1 = layout1 $+$ layout2 -- | otherwise = layout1 $$ layout2 I've also implemented the specification in HughesPJQuickCheck.hs, and checked them against the patched pretty printer. Concerning Bug #1337: ~~~~~~~~~~~~~~~~~~~~~ If the above formal specification is fine, it is easy to fix: elide the nests of (oneLiner p2) [see attached patch, record bug #1337]. > PrettyPrint(0) $ ./Bug1337 > ....ab > ...c The (long) explanation follows below. =========================================================== Explanation of Bug #1337: Consider > fcat [ nest 1 $ text "a", nest 2 $ text "b", text "c"] --> expected: (nest 1; text "a"; text "b"; nest -3; "c") --> actual : (nest 1; text "a"; text "b"; nest -5; "c") Reduction: === (nest 1; text a) <> (fill (-2) (p2:ps)) ==> (nest 2 (text "b") $+$ text "c") ==> (nest 2 (text "b")) `nilabove` (nest (-3) (text "c")) ==> (nest 1; text a; text b; nest -5 c) The problem is that if we decide to layout (p1:p2:ps) as | p1 p2 | ps (call it layout A), then we want to have > (p1 <> p2) $+$ ps. But following law this means that > fcat_A [p1:nest k p2:ps] is equivalent to > fcat_A [p1,p2,ps] so the nest of p2 has to be removed. This is somewhat similar to bug #667, but easier to fix from a semantic point of view: p1,p2 and ps are distinct layouts - we only have to preserve the individual layouts, and no combinations of them. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 09:23:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 09:23:08 -0000 Subject: [GHC] #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` In-Reply-To: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> References: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> Message-ID: <060.0e8a5e33bbed4e84b2e4b05f31c61f9b@haskell.org> #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1062, #1176, | Differential Revisions: #7666, #8809 | Phab:D1130, Phab:D1132 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"85bf76a8f8015ed6adb65095d53d8af933080354/ghc" 85bf76a8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="85bf76a8f8015ed6adb65095d53d8af933080354" Pretty: show rational as is (#10735) Following libraries/pretty. I'm not sure why it converted to Double before. This function isn't used by GHC itself. It is exported from these two places: * compiler/utils/Outputable * libraries/template-haskell/Language/Haskell/TH/PprLib.hs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 09:23:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 09:23:08 -0000 Subject: [GHC] #667: Efficient Map <-> Set conversions In-Reply-To: <049.9cbebdcde0e44f9fd9606d60e62aed5b@haskell.org> References: <049.9cbebdcde0e44f9fd9606d60e62aed5b@haskell.org> Message-ID: <064.5c6d47c9fe8a716686077e455cd69159@haskell.org> #667: Efficient Map <-> Set conversions ---------------------------------+----------------------------------------- Reporter: jpbernardy | Owner: jpbernardy Type: feature | Status: closed request | Priority: normal | Milestone: Not GHC Component: | Version: 6.4.1 libraries/base | Resolution: wontfix | Keywords: Data Map Set collections Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Test Case: N/A | ---------------------------------+----------------------------------------- Comment (by Thomas Miedema ): In [changeset:"bcfae08c0be0fa8604e2025733dfae57e37c2083/ghc" bcfae08c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bcfae08c0be0fa8604e2025733dfae57e37c2083" Pretty: fix potential bad formatting of error message (#10735) This is a backport of a bug fix by Benedikt Huber for the same problem in the pretty library (#1337), from commit 8d8866a8379c2fe8108ef034893c59e06d5e752f. The original explanation for the fix is attached below. Ticket #1776 originally reported an infinite loop when printing error message. This promptly got fixed in: commit 2d52ee06786e5caf0c2d65a4b4bb7c45c6493190 Author: simonpj at microsoft.com Date: Thu Mar 1 11:45:13 2007 +0000 Do not go into an infinite loop when pretty-printer finds a negative indent (Trac #1176) SPJ reports in the ticket: "So infinite loop is fixed, but the bad formatting remains. I've added a test, tcfail177." tcfail177 however hasn't triggered the formatting problem for years (as Ian reported in c9e0e6067a47c574d9ff3721afe58e30ca1be3e4). This patch updates the test to a version that at least still failed with ghc-7.0 (from #1776#comment:7). ------------------- From https://mail.haskell.org/pipermail/libraries/2008-June/010013.html, by Benedikt Huber: Concerning ticket #1337, we have to change the formal specification of fill (it doesn't match the implementation): -- Current Specification: -- fill [] = empty -- fill [p] = p -- fill (p1:p2:ps) = oneLiner p1 <#> nest (length p1) -- (fill (oneLiner p2 : ps)) -- `union` -- p1 $$ fill ps Problem 1: We want to `unnest' the second argument of (p1 $$ fill ps), but not the first one In the definition above we have e.g. > getSecondLayout $ > fillDef False [text "a", text "b", text "a"] >> text "ab"; nilabove; nest -1; text "a"; empty >> |ab| >> |.a| Problem 2: The overlapping $$ should only be used for those layouts of p1 which aren't one liners (otherwise violating the invariant "Left union arg has shorter first line"). I suggest the following specification (i believe it almost matches the current implementation, modulo [fillNB: fix bug #1337] (see below): -- Revised Specification: -- fill g docs = fill' 0 docs -- gap g = if g then 1 else 0 -- fill' n [] = [] -- fill' n [p] = [p] -- fill' n (p1:p2:ps) = -- oneLiner p1 (fill' (n+length p1+gap g) (oneLiner p2 : ps)) -- `union` -- (p1 $*$ nest (-n) (fill' g ps)) -- -- $*$ is defined for layouts (One-Layout Documents) as -- -- layout1 $*$ layout2 | isOneLiner layout1 = layout1 $+$ layout2 -- | otherwise = layout1 $$ layout2 I've also implemented the specification in HughesPJQuickCheck.hs, and checked them against the patched pretty printer. Concerning Bug #1337: ~~~~~~~~~~~~~~~~~~~~~ If the above formal specification is fine, it is easy to fix: elide the nests of (oneLiner p2) [see attached patch, record bug #1337]. > PrettyPrint(0) $ ./Bug1337 > ....ab > ...c The (long) explanation follows below. =========================================================== Explanation of Bug #1337: Consider > fcat [ nest 1 $ text "a", nest 2 $ text "b", text "c"] --> expected: (nest 1; text "a"; text "b"; nest -3; "c") --> actual : (nest 1; text "a"; text "b"; nest -5; "c") Reduction: === (nest 1; text a) <> (fill (-2) (p2:ps)) ==> (nest 2 (text "b") $+$ text "c") ==> (nest 2 (text "b")) `nilabove` (nest (-3) (text "c")) ==> (nest 1; text a; text b; nest -5 c) The problem is that if we decide to layout (p1:p2:ps) as | p1 p2 | ps (call it layout A), then we want to have > (p1 <> p2) $+$ ps. But following law this means that > fcat_A [p1:nest k p2:ps] is equivalent to > fcat_A [p1,p2,ps] so the nest of p2 has to be removed. This is somewhat similar to bug #667, but easier to fix from a semantic point of view: p1,p2 and ps are distinct layouts - we only have to preserve the individual layouts, and no combinations of them. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 09:28:02 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 09:28:02 -0000 Subject: [GHC] #1776: type families : couldn't match type "Elem a" against type "Elem a" In-Reply-To: <044.4a6ff2b352cb037a5d1ac3a7261867d6@haskell.org> References: <044.4a6ff2b352cb037a5d1ac3a7261867d6@haskell.org> Message-ID: <059.b0cc173fc5a9ff50e06728e50098a592@haskell.org> #1776: type families : couldn't match type "Elem a" against type "Elem a" -------------------------------------+------------------------------------- Reporter: guest | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * failure: => None/Unknown Comment: Sorry, wrong ticket number. Should have been #1176 instead of #1776. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 09:30:41 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 09:30:41 -0000 Subject: [GHC] #1176: Infinite loop when printing error message In-Reply-To: <064.2f219b840bdf4c0010ac5cb2a55fa8db@haskell.org> References: <064.2f219b840bdf4c0010ac5cb2a55fa8db@haskell.org> Message-ID: <079.01e49e1195b1bccc09d65fffbfb44598@haskell.org> #1176: Infinite loop when printing error message -------------------------------------+------------------------------------- Reporter: Paul_Berry@? | Owner: | thorkilnaur Type: bug | Status: closed Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 6.6 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: tcfail177 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * milestone: ? => 7.12.1 Comment: The underlying problem should now be fixed. Where it says #1776 in the above commit message, please read #1176. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 09:34:07 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 09:34:07 -0000 Subject: [GHC] #10756: Allow users to indicate inaccessible patterns In-Reply-To: <044.44fc866587983798150a57353bc7bdbd@haskell.org> References: <044.44fc866587983798150a57353bc7bdbd@haskell.org> Message-ID: <059.8178ed389386afd1e8d886e095344936@haskell.org> #10756: Allow users to indicate inaccessible patterns -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): == Proposal An `ImpossibleCases` language extension is introduced which turns `impossible` into a keyword when enabled. This keyword can be inserted in the place of a right-hand-side of an equation or case alternative to indicate that the left-hand-side pattern is ill-typed. This is useful for clarifying the meaning of the code to later readers as well as satisfying exhaustiveness warnings when the exhaustiveness check is unable to see that the pattern is ill-typed. To demonstrate this let's consider a standard dependently-typed vector, {{{#!hs data Vect (n::Nat) a where (:::) :: a -> Vect (n-1) a -> Vect n a Nil :: Vect 0 a }}} Perhaps we want a `head` operation on this type (note that this is a toy example; GHC's exhaustiveness checker currently has no trouble identifying the `Nil` case as impossible). An equation would look something like, {{{#!hs head :: (KnownNat (n :: Nat)) => Vect (n+1) a -> a head Nil impossible head (a:::_) = a }}} A case analysis would look like, {{{#!hs head :: (KnownNat (n :: Nat)) => Vect (n+1) a -> a head x = case x of Nil impossible a:::_ -> a }}} This could also be used in `LambdaCase` expressions, {{{#!hs head :: (KnownNat (n :: Nat)) => Vect (n+1) a -> a head = \case Nil impossible a:::_ -> a }}} When the exhaustiveness checker sees a so-marked pattern it will suppress a missing-case warning. == Related Work As noted in the ticket description, the recent (and hopefully soon to be merged) [[http://research.microsoft.com/en-us/um/people/simonpj/papers/pattern- matching/gadtpm.pdf|GADT exhaustiveness]] work will reduce the need for these annotations, however this need will not be eliminated (see the Evaluation section of the paper). Moreover even with perfect exhaustiveness detection these annotations can elucidate complex pattern matches, making it explicit to the reader which cases he needn't worry about. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 09:44:00 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 09:44:00 -0000 Subject: [GHC] #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` In-Reply-To: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> References: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> Message-ID: <060.89cba3c3cc9c6461c6872892c990d0ac@haskell.org> #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1062, #1176, | Differential Revisions: #7666, #8809 | Phab:D1130, Phab:D1132 -------------------------------------+------------------------------------- Comment (by thomie): There is 1 commit left for parity with pretty-1.1.2.0. I have not landed it yet, because I haven't been able to measure the supposed space/time improvement yet. The other 2 commits described below seem to suggest this commit doesn't actually work: "Pretty: improving the space/time performance of vcat, hsep, hcat" There are 2 commits left for parity with pretty-1.1.2.1. I have not landed them yet, because they seem to cause more allocation in the compiler (see discussion in https://github.com/haskell/pretty/pull/9): "Resolve foldr-strictness stack overflow bug" "Special-case reduce for horiz/vert" The commits are here: https://github.com/thomie/ghc/commits/pretty -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 12:20:59 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 12:20:59 -0000 Subject: [GHC] #10756: Allow users to indicate inaccessible patterns In-Reply-To: <044.44fc866587983798150a57353bc7bdbd@haskell.org> References: <044.44fc866587983798150a57353bc7bdbd@haskell.org> Message-ID: <059.337ad2ea5742f60cad365bfd78f79348@haskell.org> #10756: Allow users to indicate inaccessible patterns -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Thanks for writing that up. I like it. My only complaint is the choice of the word `impossible`, which becomes a full-fledged keyword under this proposal. If someone wants to use `ImpossibleCases` and they import a symbol named `impossible`, can they use it? I suppose using it qualified wouldn't conflict. And no exported symbol named `impossible` comes up at http://www.stackage.org/lts-2.22/hoogle?q=impossible I don't have a better suggestion among the set of keywords/keyoperators. So I vote +1 for the proposal exactly as is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 12:34:01 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 12:34:01 -0000 Subject: [GHC] #5273: error and undefined should print a location In-Reply-To: <047.0c5631d5110d7e8dd17fdeae86e25a82@haskell.org> References: <047.0c5631d5110d7e8dd17fdeae86e25a82@haskell.org> Message-ID: <062.08868ca4222ec308a754b49585e1da38@haskell.org> #5273: error and undefined should print a location -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: feature request | Status: patch Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 7.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D861 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D861 Comment: This should be addressed by Phab:D861. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 12:40:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 12:40:27 -0000 Subject: [GHC] #1404: allow more type signatures In-Reply-To: <051.dfa568640e1dd248858fc0d0c4576734@haskell.org> References: <051.dfa568640e1dd248858fc0d0c4576734@haskell.org> Message-ID: <066.0f230447b4fa11a03cb85b380afccc30@haskell.org> #1404: allow more type signatures -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: Type: feature request | Status: closed Priority: normal | Milestone: ? Component: Compiler (Type | Version: 6.6.1 checker) | Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => wontfix Comment: It seems like the Backpack work addresses much of this by explicitly defining the publicly available interface of a package. Otherwise, the CPP approach proposed in comment:1 seems pretty reasonable to be. If someone wants to take up this task and see whether there is consensus around allowing multiple signatures then feel free to reopen this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 12:43:12 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 12:43:12 -0000 Subject: [GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages In-Reply-To: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> References: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> Message-ID: <057.5a2fb3dd7a1df7a071e5c9d916cb7012@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------- Reporter: nh2 | Owner: gridaphobe Type: feature request | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 5273 | Differential Revisions: Phab:D578 -------------------------------------+------------------------------------- Changes (by edsko): * related: => 5273 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 12:44:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 12:44:32 -0000 Subject: [GHC] #624: Program location for thread error messages In-Reply-To: <043.6970ec0cf9ee8d1b610482ac894432c0@haskell.org> References: <043.6970ec0cf9ee8d1b610482ac894432c0@haskell.org> Message-ID: <058.8faa987bb30fe23969b4c4cc8e0b3e8d@haskell.org> #624: Program location for thread error messages -------------------------------------+------------------------------------- Reporter: chak | Owner: Type: task | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: None Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): It seems like the recently merge implicit-parameter-based stack-trace work (see Phab:D578) would be quite useful for this. Blocking actions could take an implicit `SrcLoc` which could be providing along with the error in the event of indefinite blocking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 12:46:21 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 12:46:21 -0000 Subject: [GHC] #5273: error and undefined should print a location In-Reply-To: <047.0c5631d5110d7e8dd17fdeae86e25a82@haskell.org> References: <047.0c5631d5110d7e8dd17fdeae86e25a82@haskell.org> Message-ID: <062.76ad89948cf6476518ffa430d48673e3@haskell.org> #5273: error and undefined should print a location -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: feature request | Status: patch Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 7.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 9049 | Differential Revisions: Phab:D861 -------------------------------------+------------------------------------- Changes (by edsko): * related: => 9049 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 13:02:33 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 13:02:33 -0000 Subject: [GHC] #1687: A faster (^)-function. In-Reply-To: <064.1e051c3fce5c2da263cdc0424cf20634@haskell.org> References: <064.1e051c3fce5c2da263cdc0424cf20634@haskell.org> Message-ID: <079.516f0ba1e4589f85829df4b4f30449b6@haskell.org> #1687: A faster (^)-function. -------------------------------------+------------------------------------- Reporter: moonlite@? | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Prelude | Version: 6.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 13:39:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 13:39:27 -0000 Subject: [GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages In-Reply-To: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> References: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> Message-ID: <057.b3dbada4117ac32917a867a417d7a0b0@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------- Reporter: nh2 | Owner: gridaphobe Type: feature request | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5273, #624 | Differential Revisions: Phab:D578 -------------------------------------+------------------------------------- Changes (by bgamari): * related: 5273 => #5273, #624 Comment: One thing that we may want to consider is using this mechanism to address #624, which seeks backtraces for indefinitely blocking MVar and STM operations. The only slightly tricky thing here is that you would need to pipe the backtrace through the RTS. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 13:59:37 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 13:59:37 -0000 Subject: [GHC] #9143: feature request: way to set actual program argv In-Reply-To: <047.14769c1c2bab59d46b7097edaaa12dc6@haskell.org> References: <047.14769c1c2bab59d46b7097edaaa12dc6@haskell.org> Message-ID: <062.1b627e2145b6369c1b3bef97d5696cfe@haskell.org> #9143: feature request: way to set actual program argv -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > It's not currently possible to write a program with ghc that changes its > argv, so as to change what the program name/parameters appear to be in > ps. > > An example of a program that does this is sshd, which arranges for the > process name to say which user it's serving. For example, "sshd: joey > [priv]" > > I'd like to be able to write such programs using haskell too. Also, I > have a haskell program that, due to the way it is executed, has a really > horrible display in ps: > > /usr/local/propellor/docker/android-git-annex- > builder.orca.kitenet.net.propellor.shim/lib64/ld-linux-x86-64.so.2 > --library-path /usr/local/propellor/docker/android-git-annex- > builder.orca.kitenet.net.propellor.shim/lib/x86_64-linux- > gnu:/usr/local/propellor/docker/android-git-annex- > builder.orca.kitenet.net.propellor.shim/usr/lib/x86_64-linux- > gnu:/usr/local/propellor/docker/android-git-annex- > builder.orca.kitenet.net.propellor.shim/lib64:/usr/local/propellor/docker > /android-git-annex- > builder.orca.kitenet.net.propellor.shim/etc/ld.so.conf.d:/usr/local/propellor/docker > /android-git-annex-builder.orca.kitenet.net.propellor.shim/usr/lib/x86_64 > -linux-gnu/audit:/usr/local/propellor/docker/android-git-annex- > builder.orca.kitenet.net.propellor.shim/usr/lib/x86_64-linux-gnu/gconv > /usr/local/propellor/propellor > > That's enough motivation for me to dig into this. :) > > In rts/RtsMain.c, progargv is set to point to argv. However, it's static, > so this cannot be (ab)used from the FFI to change argv. > > So, a minimal change would be to make progargv not be static, and perhaps > give it a more formal name or minimal FFI binding. A GHC-specific library > could then use this to modify argv. > > The haskell interface I'm considering would be: > > displayArgv :: [String] -> IO () > > It would need to truncate strings to fit within the available argv space. > > (This would not affect the argv used by System.Environment, which is a > copy of argv.) New description: It's not currently possible to write a program with ghc that changes its argv, so as to change what the program name/parameters appear to be in ps. An example of a program that does this is sshd, which arranges for the process name to say which user it's serving. For example, "sshd: joey [priv]" I'd like to be able to write such programs using haskell too. Also, I have a haskell program that, due to the way it is executed, has a really horrible display in ps: {{{ /usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/lib64/ld-linux-x86-64.so.2 --library-path /usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/lib/x86_64-linux- gnu:/usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/usr/lib/x86_64-linux- gnu:/usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/lib64:/usr/local/propellor/docker /android-git-annex- builder.orca.kitenet.net.propellor.shim/etc/ld.so.conf.d:/usr/local/propellor/docker /android-git-annex-builder.orca.kitenet.net.propellor.shim/usr/lib/x86_64 -linux-gnu/audit:/usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/usr/lib/x86_64-linux-gnu/gconv /usr/local/propellor/propellor }}} That's enough motivation for me to dig into this. :) In rts/RtsMain.c, progargv is set to point to argv. However, it's static, so this cannot be (ab)used from the FFI to change argv. So, a minimal change would be to make progargv not be static, and perhaps give it a more formal name or minimal FFI binding. A GHC-specific library could then use this to modify argv. The haskell interface I'm considering would be: {{{ displayArgv :: [String] -> IO () }}} It would need to truncate strings to fit within the available argv space. (This would not affect the argv used by `System.Environment`, which is a copy of argv.) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 14:11:50 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 14:11:50 -0000 Subject: [GHC] #9143: feature request: way to set actual program argv In-Reply-To: <047.14769c1c2bab59d46b7097edaaa12dc6@haskell.org> References: <047.14769c1c2bab59d46b7097edaaa12dc6@haskell.org> Message-ID: <062.fdb87de206d0cb18a05c9cb6e87f6cc1@haskell.org> #9143: feature request: way to set actual program argv -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): The cross-platform implications really worry me here. For instance, it's recommended that you do not modify `argv` at all on [[http://stackoverflow.com/questions/29158052/changing-argv0-with- winapi|Windows]]. Do we know that this is really safe (or will even accomplish the desired effect) on all of the platforms that GHC supports (FreeBSD, OpenBSD, Darwin, Linux, Solaris, and Windows, where it is not)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 14:21:03 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 14:21:03 -0000 Subject: [GHC] #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` In-Reply-To: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> References: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> Message-ID: <060.d14337034b21bef27572df05bdbc604f@haskell.org> #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1062, #1176, | Differential Revisions: #7666, #8809 | Phab:D1130, Phab:D1132 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"f903949beee3a4e0a925003b5553066c9f513c11/ghc" f903949/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f903949beee3a4e0a925003b5553066c9f513c11" Pretty: improving the space/time performance of vcat, hsep, hcat (#10735) After 5d57087e314bd484dbe14958f9b422be3ac6641a ("Pretty: fix a broken invariant"), T3294 showed 50% more max_bytes_used (#3294). After this commit, max_bytes_used is back to what it was before, and the test passes again. This is a backport of a bug fix by Benedikt Huber (#2393), from commit 1e50748beaa4bd2281d323b18ea51c786bba04a1 in the pretty library. From https://mail.haskell.org/pipermail/libraries/2008-June/009991.html: vcat (hsep,cat) is implemented in an unneccessarily strict way. We only get some output after all of vcat's arguments are evaluated and checked against being Empty. This can be improved by only checking the right argument of foldr against being Empty, and then applying an Empty-filter on the resulting Doc. Space improvement is obvious. The microbenchmark (code.haskell.org/~bhuber/Text/PrettyPrint/ HughesPJPerfCheck.hs) suggests that the improvements in time are remarkable too. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 14:21:03 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 14:21:03 -0000 Subject: [GHC] #2393: Text.PrettyPrint.HughesPJ: Bug fixes, performance improvement In-Reply-To: <044.a2eb2249d4c87d53c08ed2cb37607972@haskell.org> References: <044.a2eb2249d4c87d53c08ed2cb37607972@haskell.org> Message-ID: <059.84695277dc42d70eb17d6602f92ae84e@haskell.org> #2393: Text.PrettyPrint.HughesPJ: Bug fixes, performance improvement -------------------------------------+--------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: libraries/pretty | Version: 6.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Test Case: | -------------------------------------+--------------------------------- Comment (by Thomas Miedema ): In [changeset:"f903949beee3a4e0a925003b5553066c9f513c11/ghc" f903949/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f903949beee3a4e0a925003b5553066c9f513c11" Pretty: improving the space/time performance of vcat, hsep, hcat (#10735) After 5d57087e314bd484dbe14958f9b422be3ac6641a ("Pretty: fix a broken invariant"), T3294 showed 50% more max_bytes_used (#3294). After this commit, max_bytes_used is back to what it was before, and the test passes again. This is a backport of a bug fix by Benedikt Huber (#2393), from commit 1e50748beaa4bd2281d323b18ea51c786bba04a1 in the pretty library. From https://mail.haskell.org/pipermail/libraries/2008-June/009991.html: vcat (hsep,cat) is implemented in an unneccessarily strict way. We only get some output after all of vcat's arguments are evaluated and checked against being Empty. This can be improved by only checking the right argument of foldr against being Empty, and then applying an Empty-filter on the resulting Doc. Space improvement is obvious. The microbenchmark (code.haskell.org/~bhuber/Text/PrettyPrint/ HughesPJPerfCheck.hs) suggests that the improvements in time are remarkable too. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 14:21:03 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 14:21:03 -0000 Subject: [GHC] #3294: Large compilation time/memory consumption In-Reply-To: <046.0a15417e538aeef3254b5152fea74b37@haskell.org> References: <046.0a15417e538aeef3254b5152fea74b37@haskell.org> Message-ID: <061.d716191ac0dcc1438015cc5e80740dfa@haskell.org> #3294: Large compilation time/memory consumption -------------------------------------------------+------------------------- Reporter: pumpkin | Owner: simonmar Type: bug | Status: closed Priority: low | Milestone: 7.4.1 Component: Compiler | Version: 6.10.3 Resolution: wontfix | Keywords: Operating System: MacOS X | Architecture: x86 Type of failure: Compile-time performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------------------+------------------------- Comment (by Thomas Miedema ): In [changeset:"f903949beee3a4e0a925003b5553066c9f513c11/ghc" f903949/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f903949beee3a4e0a925003b5553066c9f513c11" Pretty: improving the space/time performance of vcat, hsep, hcat (#10735) After 5d57087e314bd484dbe14958f9b422be3ac6641a ("Pretty: fix a broken invariant"), T3294 showed 50% more max_bytes_used (#3294). After this commit, max_bytes_used is back to what it was before, and the test passes again. This is a backport of a bug fix by Benedikt Huber (#2393), from commit 1e50748beaa4bd2281d323b18ea51c786bba04a1 in the pretty library. From https://mail.haskell.org/pipermail/libraries/2008-June/009991.html: vcat (hsep,cat) is implemented in an unneccessarily strict way. We only get some output after all of vcat's arguments are evaluated and checked against being Empty. This can be improved by only checking the right argument of foldr against being Empty, and then applying an Empty-filter on the resulting Doc. Space improvement is obvious. The microbenchmark (code.haskell.org/~bhuber/Text/PrettyPrint/ HughesPJPerfCheck.hs) suggests that the improvements in time are remarkable too. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 14:32:45 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 14:32:45 -0000 Subject: [GHC] #10221: LLVM backend does not work on OSX (was: LLVM does not work on OSX) In-Reply-To: <046.a27bcc824218c152901bbcce2f7fae6d@haskell.org> References: <046.a27bcc824218c152901bbcce2f7fae6d@haskell.org> Message-ID: <061.a469e9f29a4aee5359fe05be00d94390@haskell.org> #10221: LLVM backend does not work on OSX -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): yongqli, is this resolved? Starting with GHC 7.12 we'll be (optionally) shipping LLVM alongside GHC which should hopefully prevent this sort of issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 14:33:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 14:33:08 -0000 Subject: [GHC] #10221: LLVM backend does not work on OSX In-Reply-To: <046.a27bcc824218c152901bbcce2f7fae6d@haskell.org> References: <046.a27bcc824218c152901bbcce2f7fae6d@haskell.org> Message-ID: <061.f4b3b3a5dfab0a8138048e463a33ca2f@haskell.org> #10221: LLVM backend does not work on OSX -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 14:36:43 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 14:36:43 -0000 Subject: [GHC] #10768: Location information of LHsModule is incorrect Message-ID: <046.99b5a2d9e044c3653d6b967add4eb201@haskell.org> #10768: Location information of LHsModule is incorrect -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: #597 Differential Revisions: | -------------------------------------+------------------------------------- The location assigned by the parser to `LHsModule`s is incorrect: it is a point span at (1,0) rather then a span encompassing the entire file. This was taken from #597, which also included a number of other similar issues, all of which are now resolved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 14:37:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 14:37:27 -0000 Subject: [GHC] #597: Various error messages have inaccurate source locations In-Reply-To: <047.d9b3aa24ce12758448e171cbecc1a26d@haskell.org> References: <047.d9b3aa24ce12758448e171cbecc1a26d@haskell.org> Message-ID: <062.e360cd31dc5e76e42e5fa5c9826cd4a3@haskell.org> #597: Various error messages have inaccurate source locations -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: closed Priority: low | Milestone: ? Component: Compiler | Version: None Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10768 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: None => fixed * related: => #10768 Comment: Closing as all but one of these issues have been resolved. The remaining issue will be tracked by #10768. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 14:42:20 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 14:42:20 -0000 Subject: [GHC] #9143: feature request: way to set actual program argv In-Reply-To: <047.14769c1c2bab59d46b7097edaaa12dc6@haskell.org> References: <047.14769c1c2bab59d46b7097edaaa12dc6@haskell.org> Message-ID: <062.44a6f3a87270cef48a253b9621499426@haskell.org> #9143: feature request: way to set actual program argv -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by pgj): As far as I know, on FreeBSD, the recommended method for changing the value of `argv[0]` is calling the [https://www.freebsd.org/cgi/man.cgi?query=setproctitle&sektion=3 setproctitle(3)] function. I am not sure if rest of `argv` could be changed safely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 14:54:19 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 14:54:19 -0000 Subject: [GHC] #9868: ghc: panic! Dynamic linker not initialised In-Reply-To: <046.5f3f9e960e287bc6e82a07e7ce17a8b6@haskell.org> References: <046.5f3f9e960e287bc6e82a07e7ce17a8b6@haskell.org> Message-ID: <061.f170b9a853efaaee4125090d86cd0913@haskell.org> #9868: ghc: panic! Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: Jamedjo | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: I'm not really sure what we can do with this bug as is as there isn't enough information here to reproduce the crash. Moreover, it looks two of the issues reported here are distinct from the panic which apparently provoked the ticket. Could those affected by this see if they can reproduce the issue on GHC 7.10.2 and if so provide a detailed set of steps to reproduce the issue? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 14:57:25 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 14:57:25 -0000 Subject: [GHC] #3704: Using -shared without -dynamic should be rejected on linux In-Reply-To: <048.04c7c9d4780f94b6d12f6cbf7be90e6c@haskell.org> References: <048.04c7c9d4780f94b6d12f6cbf7be90e6c@haskell.org> Message-ID: <063.0c8ffdba266cc62757b47c0ad71825ac@haskell.org> #3704: Using -shared without -dynamic should be rejected on linux -------------------------------------+------------------------------------- Reporter: asuffield | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.12.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: I am going to close this as it appears that `-dynamic-lib` is now available. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 14:59:16 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 14:59:16 -0000 Subject: [GHC] #3704: Using -shared without -dynamic should be rejected on linux In-Reply-To: <048.04c7c9d4780f94b6d12f6cbf7be90e6c@haskell.org> References: <048.04c7c9d4780f94b6d12f6cbf7be90e6c@haskell.org> Message-ID: <063.847842fed75a7ce5bf883ba693a4f0f0@haskell.org> #3704: Using -shared without -dynamic should be rejected on linux -------------------------------------+------------------------------------- Reporter: asuffield | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.12.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Actually it appears that it is not yet available (see #3712) but there isn't really a clear course of action on this bug otherwise so I'm going to leave this closed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 15:00:34 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 15:00:34 -0000 Subject: [GHC] #10295: Putting SCC in heavily inlined code results in "error: redefinition of global" In-Reply-To: <046.adbcfa466714e863665bb32dacf6e5dc@haskell.org> References: <046.adbcfa466714e863665bb32dacf6e5dc@haskell.org> Message-ID: <061.0cbd90b7fb65476243f8386680227d77@haskell.org> #10295: Putting SCC in heavily inlined code results in "error: redefinition of global" -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * failure: None/Unknown => Compile-time crash Comment: Any update here, yongqli? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 15:04:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 15:04:32 -0000 Subject: [GHC] #3712: Implement -dynamic-lib option In-Reply-To: <047.0ba626c454f1d59815233fb1be60c8e4@haskell.org> References: <047.0ba626c454f1d59815233fb1be60c8e4@haskell.org> Message-ID: <062.7ed2f499fff6df7db60fc9683f123694@haskell.org> #3712: Implement -dynamic-lib option -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 6.12.1 RC1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Simon, do you intend on picking this up? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 15:09:05 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 15:09:05 -0000 Subject: [GHC] #624: Program location for thread error messages In-Reply-To: <043.6970ec0cf9ee8d1b610482ac894432c0@haskell.org> References: <043.6970ec0cf9ee8d1b610482ac894432c0@haskell.org> Message-ID: <058.72a5899eef0a111d083634ebf48526ae@haskell.org> #624: Program location for thread error messages -------------------------------------+------------------------------------- Reporter: chak | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: None Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: ? => 7.12.1 Comment: It seems like we have the pieces in place to address this in 7.12. Milestoning appropriately There are a few questions that remain, however, * What sort of stack trace should the exception carry? At the moment we have a number of source location representations scattered about `base` (which will hopefully soon be cleaned up; see #10068) * Do we want backtraces to be enabled by default? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 15:13:30 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 15:13:30 -0000 Subject: [GHC] #624: Program location for thread error messages In-Reply-To: <043.6970ec0cf9ee8d1b610482ac894432c0@haskell.org> References: <043.6970ec0cf9ee8d1b610482ac894432c0@haskell.org> Message-ID: <058.6f3fef07bd74b56a9397cee7d04af761@haskell.org> #624: Program location for thread error messages -------------------------------------+------------------------------------- Reporter: chak | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: None Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gridaphobe): * cc: gridaphobe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 15:20:16 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 15:20:16 -0000 Subject: [GHC] #1687: A faster (^)-function. In-Reply-To: <064.1e051c3fce5c2da263cdc0424cf20634@haskell.org> References: <064.1e051c3fce5c2da263cdc0424cf20634@haskell.org> Message-ID: <079.b19cc51a7e416855e2c1fa7b3269e6b8@haskell.org> #1687: A faster (^)-function. -------------------------------------+------------------------------------- Reporter: moonlite@? | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Prelude | Version: 6.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * cc: hvr (added) Comment: hvr, what do you think about this? Perhaps integer_gmp could wrap `mpz_pow_ui`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 15:33:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 15:33:28 -0000 Subject: [GHC] #9868: ghc: panic! Dynamic linker not initialised In-Reply-To: <046.5f3f9e960e287bc6e82a07e7ce17a8b6@haskell.org> References: <046.5f3f9e960e287bc6e82a07e7ce17a8b6@haskell.org> Message-ID: <061.8d0627741f43c425498cbdb231fb4f6b@haskell.org> #9868: ghc: panic! Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: Jamedjo | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by mpickering): I can't reproduce this with 7.10.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 15:36:35 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 15:36:35 -0000 Subject: [GHC] #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 In-Reply-To: <047.bc42599240078110c16528fec3996433@haskell.org> References: <047.bc42599240078110c16528fec3996433@haskell.org> Message-ID: <062.21bf43d41b812c6477a3986f280ca7a1@haskell.org> #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 -------------------------------------+------------------------------------- Reporter: malcolmw | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: windows, | exceptions Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #10726 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7b211b4e5a38efca437d76ea442495370da7cc9a/ghc" 7b211b4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7b211b4e5a38efca437d76ea442495370da7cc9a" Upgrade GCC to 5.2.0 for Windows x86 and x86_64 This patch does a few things - Moved GHC x86 to MinGW-w64 (Using Awson's patch) - Moves Both GHCs to MSYS2 toolchains - Completely removes the dependencies on the git tarball repo - Downloads only the required tarball for the architecture for which we are building - Downloads the perl tarball is missing as well - Fixed a few bugs in the linker to fix tests on Windows The links currently point to repo.msys2.org and GitHub, it might be more desirable to mirror them on http://downloads.haskell.org/~ghc/mingw/ as with the previous patch attempt. For more details on what the MSYS2 packages I include see #10726 (Awson's comment). but it should contain all we need and no python or fortran, which makes the uncompressed tar a 1-2 hundreds mb smaller. The `GCC 5.2.0` in the package supports `libgcc` as a shared library, this is a problem since when compiling with -shared the produced dll now has a dependency on `libgcc_s_sjlj-1.dll`. To solve this the flag `-static-libgcc` is now being used for all GCC calls on windows. Test Plan: ./validate was ran both on x86 and x86_64 windows and compared against the baseline. A few test were failing due to Ld no longer being noisy. These were updated. The changes to the configure script *should* be validated by the build bots for the other platforms before landing Reviewers: simonmar, awson, bgamari, austin, thomie Reviewed By: thomie Subscribers: #ghc_windows_task_force, thomie, awson Differential Revision: https://phabricator.haskell.org/D1123 GHC Trac Issues: #10726, #9014, #9218, #10435 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 15:36:35 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 15:36:35 -0000 Subject: [GHC] #9218: Upgrade the version of MinGW shipped with GHC In-Reply-To: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> References: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> Message-ID: <062.b36ebe2525786f649eb225fff90743c0@haskell.org> #9218: Upgrade the version of MinGW shipped with GHC -------------------------------------+------------------------------------- Reporter: komadori | Owner: gintas Type: task | Status: patch Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9014 | Blocking: 9215 Related Tickets: #3390 #10705 | Differential Revisions: Phab:D339 #10726 | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7b211b4e5a38efca437d76ea442495370da7cc9a/ghc" 7b211b4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7b211b4e5a38efca437d76ea442495370da7cc9a" Upgrade GCC to 5.2.0 for Windows x86 and x86_64 This patch does a few things - Moved GHC x86 to MinGW-w64 (Using Awson's patch) - Moves Both GHCs to MSYS2 toolchains - Completely removes the dependencies on the git tarball repo - Downloads only the required tarball for the architecture for which we are building - Downloads the perl tarball is missing as well - Fixed a few bugs in the linker to fix tests on Windows The links currently point to repo.msys2.org and GitHub, it might be more desirable to mirror them on http://downloads.haskell.org/~ghc/mingw/ as with the previous patch attempt. For more details on what the MSYS2 packages I include see #10726 (Awson's comment). but it should contain all we need and no python or fortran, which makes the uncompressed tar a 1-2 hundreds mb smaller. The `GCC 5.2.0` in the package supports `libgcc` as a shared library, this is a problem since when compiling with -shared the produced dll now has a dependency on `libgcc_s_sjlj-1.dll`. To solve this the flag `-static-libgcc` is now being used for all GCC calls on windows. Test Plan: ./validate was ran both on x86 and x86_64 windows and compared against the baseline. A few test were failing due to Ld no longer being noisy. These were updated. The changes to the configure script *should* be validated by the build bots for the other platforms before landing Reviewers: simonmar, awson, bgamari, austin, thomie Reviewed By: thomie Subscribers: #ghc_windows_task_force, thomie, awson Differential Revision: https://phabricator.haskell.org/D1123 GHC Trac Issues: #10726, #9014, #9218, #10435 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 15:36:35 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 15:36:35 -0000 Subject: [GHC] #9014: GHC 7.8.2 Win64 tarball includes gfortran/gcj/python In-Reply-To: <045.6b2d2b3d1bd35df290e16aad746006bd@haskell.org> References: <045.6b2d2b3d1bd35df290e16aad746006bd@haskell.org> Message-ID: <060.7d628d4f53d305289a3acdb4fb062669@haskell.org> #9014: GHC 7.8.2 Win64 tarball includes gfortran/gcj/python ---------------------------------+----------------------------------------- Reporter: refold | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: 9218 Related Tickets: #10726 #9218 | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by Ben Gamari ): In [changeset:"7b211b4e5a38efca437d76ea442495370da7cc9a/ghc" 7b211b4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7b211b4e5a38efca437d76ea442495370da7cc9a" Upgrade GCC to 5.2.0 for Windows x86 and x86_64 This patch does a few things - Moved GHC x86 to MinGW-w64 (Using Awson's patch) - Moves Both GHCs to MSYS2 toolchains - Completely removes the dependencies on the git tarball repo - Downloads only the required tarball for the architecture for which we are building - Downloads the perl tarball is missing as well - Fixed a few bugs in the linker to fix tests on Windows The links currently point to repo.msys2.org and GitHub, it might be more desirable to mirror them on http://downloads.haskell.org/~ghc/mingw/ as with the previous patch attempt. For more details on what the MSYS2 packages I include see #10726 (Awson's comment). but it should contain all we need and no python or fortran, which makes the uncompressed tar a 1-2 hundreds mb smaller. The `GCC 5.2.0` in the package supports `libgcc` as a shared library, this is a problem since when compiling with -shared the produced dll now has a dependency on `libgcc_s_sjlj-1.dll`. To solve this the flag `-static-libgcc` is now being used for all GCC calls on windows. Test Plan: ./validate was ran both on x86 and x86_64 windows and compared against the baseline. A few test were failing due to Ld no longer being noisy. These were updated. The changes to the configure script *should* be validated by the build bots for the other platforms before landing Reviewers: simonmar, awson, bgamari, austin, thomie Reviewed By: thomie Subscribers: #ghc_windows_task_force, thomie, awson Differential Revision: https://phabricator.haskell.org/D1123 GHC Trac Issues: #10726, #9014, #9218, #10435 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 15:36:35 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 15:36:35 -0000 Subject: [GHC] #10726: Upgrade MingW-w64 distributions for windows In-Reply-To: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> References: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> Message-ID: <059.9efc67178480ad9fe02abab8276f6702@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: patch Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #9014 | Differential Revisions: Phab:D1123 #10435 | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7b211b4e5a38efca437d76ea442495370da7cc9a/ghc" 7b211b4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7b211b4e5a38efca437d76ea442495370da7cc9a" Upgrade GCC to 5.2.0 for Windows x86 and x86_64 This patch does a few things - Moved GHC x86 to MinGW-w64 (Using Awson's patch) - Moves Both GHCs to MSYS2 toolchains - Completely removes the dependencies on the git tarball repo - Downloads only the required tarball for the architecture for which we are building - Downloads the perl tarball is missing as well - Fixed a few bugs in the linker to fix tests on Windows The links currently point to repo.msys2.org and GitHub, it might be more desirable to mirror them on http://downloads.haskell.org/~ghc/mingw/ as with the previous patch attempt. For more details on what the MSYS2 packages I include see #10726 (Awson's comment). but it should contain all we need and no python or fortran, which makes the uncompressed tar a 1-2 hundreds mb smaller. The `GCC 5.2.0` in the package supports `libgcc` as a shared library, this is a problem since when compiling with -shared the produced dll now has a dependency on `libgcc_s_sjlj-1.dll`. To solve this the flag `-static-libgcc` is now being used for all GCC calls on windows. Test Plan: ./validate was ran both on x86 and x86_64 windows and compared against the baseline. A few test were failing due to Ld no longer being noisy. These were updated. The changes to the configure script *should* be validated by the build bots for the other platforms before landing Reviewers: simonmar, awson, bgamari, austin, thomie Reviewed By: thomie Subscribers: #ghc_windows_task_force, thomie, awson Differential Revision: https://phabricator.haskell.org/D1123 GHC Trac Issues: #10726, #9014, #9218, #10435 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 16:04:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 16:04:15 -0000 Subject: [GHC] #10769: Yet another crash from type holes Message-ID: <049.adcd25e8757381b099d00f18d1417d8a@haskell.org> #10769: Yet another crash from type holes -----------------------------------------+------------------------------- Reporter: rpglover64 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+------------------------------- {{{#!hs {-# OPTIONS_GHC -fdefer-typed-holes #-} hylo a b = h where h = b . fmap h . a foo a b = hylo a' b' where a' x = _ b' = _ bar :: [Int] bar = [] main = print bar }}} Loading this up in ghci and attempting to run main prints: {{{ GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help unknown option: 'c' [1 of 1] Compiling Main ( bad.hs, interpreted ) bad.hs:6:16: Warning: Found hole ?_? with type: t4 Where: ?t4? is a rigid type variable bound by the inferred type of a' :: t3 -> t4 at bad.hs:6:9 Relevant bindings include x :: t3 (bound at bad.hs:6:12) a' :: t3 -> t4 (bound at bad.hs:6:9) b' :: forall t. t (bound at bad.hs:7:9) b :: t1 (bound at bad.hs:5:7) a :: t (bound at bad.hs:5:5) foo :: t -> t1 -> t2 -> b (bound at bad.hs:5:1) In the expression: _ In an equation for ?a'?: a' x = _ In an equation for ?foo?: foo a b = hylo a' b' where a' x = _ b' = _ bad.hs:7:14: Warning: Found hole ?_? with type: t3 Where: ?t3? is a rigid type variable bound by the inferred type of b' :: t3 at bad.hs:7:9 Relevant bindings include b' :: t3 (bound at bad.hs:7:9) b :: t1 (bound at bad.hs:5:7) a :: t (bound at bad.hs:5:5) foo :: t -> t1 -> t2 -> b (bound at bad.hs:5:1) In the expression: _ In an equation for ?b'?: b' = _ In an equation for ?foo?: foo a b = hylo a' b' where a' x = _ b' = _ Ok, modules loaded: Main. *Main> main ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): nameModule $dFunctor_aKj Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Compiling with ghc and then running the resulting binary works. Attempting to replicate with a recent version of GHC HEAD gives {{{ GHCi, version 7.11.20150812: http://www.haskell.org/ghc/ :? for help unknown option: 'c' [1 of 1] Compiling Main ( bad.hs, interpreted ) bad.hs:5:11: error: No instance for (Functor f0) arising from a use of ?hylo? The type variable ?f0? is ambiguous Note: there are several potential instances: instance Functor Maybe -- Defined in ?GHC.Base? instance Functor IO -- Defined in ?GHC.Base? instance Functor ((->) r) -- Defined in ?GHC.Base? ...plus two others In the expression: hylo a' b' In an equation for ?foo?: foo a b = hylo a' b' where a' x = _ b' = _ Failed, modules loaded: none. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 16:13:44 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 16:13:44 -0000 Subject: [GHC] #10726: Upgrade MingW-w64 distributions for windows In-Reply-To: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> References: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> Message-ID: <059.fe3cb484c24cc32e4f10ee0f74579808@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: patch Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #9014 | Differential Revisions: Phab:D1123 #10435 | -------------------------------------+------------------------------------- Comment (by awson): Replying to [comment:3 awson]: >recently released binutils-2.25.1 which have a very important bug (wrong linking of 64-bit import libraries generated by MS linker) fixed. Strictly speaking, binutils-2.25.1 doesn't have this bug fixed, but its MSys2 build *has* the relevant patch (and a couple of other useful patches) applied. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 16:24:19 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 16:24:19 -0000 Subject: [GHC] #10726: Upgrade MingW-w64 distributions for windows In-Reply-To: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> References: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> Message-ID: <059.6891201bc70eeaa5932af27aa6b25589@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: closed Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #9014 | Differential Revisions: Phab:D1123 #10435 | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 16:25:53 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 16:25:53 -0000 Subject: [GHC] #9014: GHC 7.8.2 Win64 tarball includes gfortran/gcj/python In-Reply-To: <045.6b2d2b3d1bd35df290e16aad746006bd@haskell.org> References: <045.6b2d2b3d1bd35df290e16aad746006bd@haskell.org> Message-ID: <060.086703e4e930cb0f452601afdbf7b49a@haskell.org> #9014: GHC 7.8.2 Win64 tarball includes gfortran/gcj/python ---------------------------------+----------------------------------------- Reporter: refold | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: 9218 Related Tickets: #10726 #9218 | Differential Revisions: ---------------------------------+----------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => fixed Comment: The new builds should have a smaller footprint. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 16:26:46 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 16:26:46 -0000 Subject: [GHC] #10769: Yet another crash from typed holes (was: Yet another crash from type holes) In-Reply-To: <049.adcd25e8757381b099d00f18d1417d8a@haskell.org> References: <049.adcd25e8757381b099d00f18d1417d8a@haskell.org> Message-ID: <064.1b8c3b24d85871643e26dd2515a8b485@haskell.org> #10769: Yet another crash from typed holes -------------------------------+----------------------------------------- Reporter: rpglover64 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 16:27:12 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 16:27:12 -0000 Subject: [GHC] #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 In-Reply-To: <047.bc42599240078110c16528fec3996433@haskell.org> References: <047.bc42599240078110c16528fec3996433@haskell.org> Message-ID: <062.e58815bb65bf4eb98f0a74d292815698@haskell.org> #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 -------------------------------------+------------------------------------- Reporter: malcolmw | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: fixed | Keywords: windows, | exceptions Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #10726 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => fixed Comment: GHC x86 now uses MinGW-w64 as well, this problem no longer occurs with that toolchain. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 18:24:37 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 18:24:37 -0000 Subject: [GHC] #10769: Yet another crash from typed holes In-Reply-To: <049.adcd25e8757381b099d00f18d1417d8a@haskell.org> References: <049.adcd25e8757381b099d00f18d1417d8a@haskell.org> Message-ID: <064.b964b8ea70e57f38bb4771d118b27dae@haskell.org> #10769: Yet another crash from typed holes -------------------------------+----------------------------------------- Reporter: rpglover64 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by bgamari): I would probably say that the bug was that GHC 7.10.2 didn't realize it needed a `Functor` instance (hence crashing at runtime as it had no dictionary to provide). This appears to be fixed in `master`. The problem here is that you program is ambiguous; GHC has no way of knowing which functor you mean here. GHC will gladly help you fill in the holes of an unambiguous program, but it won't make decisions on your behalf. This can be resolved by telling GHC which functor `a'` is supposed to be. For instance, perhaps you want `a` and `a'` to be values of the same functor, {{{#!hs {-# OPTIONS_GHC -fdefer-typed-holes #-} {-# LANGUAGE ScopedTypeVariables #-} hylo :: Functor f => (a -> f a) -> (f b -> b) -> a -> b hylo a b = h where h = b . fmap h . a foo :: forall f a b. Functor f => (a -> f a) -> (f b -> b) -> a -> b foo a b = hylo a' b' where a' x = _ b' :: f b -> b b' = _ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 18:33:01 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 18:33:01 -0000 Subject: [GHC] #10769: Yet another crash from typed holes In-Reply-To: <049.adcd25e8757381b099d00f18d1417d8a@haskell.org> References: <049.adcd25e8757381b099d00f18d1417d8a@haskell.org> Message-ID: <064.896df8c48cf588c5d124546f3f048bc7@haskell.org> #10769: Yet another crash from typed holes -------------------------------+----------------------------------------- Reporter: rpglover64 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by rpglover64): Interestingly, also passing `-fdefer-type-errors` makes ghc 7.10.2 both warn about "No instance for Functor" and run successfully. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 19:53:59 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 19:53:59 -0000 Subject: [GHC] #1687: A faster (^)-function. In-Reply-To: <064.1e051c3fce5c2da263cdc0424cf20634@haskell.org> References: <064.1e051c3fce5c2da263cdc0424cf20634@haskell.org> Message-ID: <079.6eecbf493b31387713fca6c3c5ede5ba@haskell.org> #1687: A faster (^)-function. -------------------------------------+------------------------------------- Reporter: moonlite@? | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Prelude | Version: 6.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:16 bgamari]: > hvr, what do you think about this? Perhaps integer_gmp could wrap `mpz_pow_ui`? You may notice that I had actually `mpz_pow_ui` wrapped earlier for 0.5.1, see http://hackage.haskell.org/package/integer-gmp-0.5.1.0/docs/GHC-Integer- GMP-Internals.html#g:3 but I had to drop it again for `integer-gmp-1.0` because there's no easy way to predict how large the result will be. But I wanted to revisit this at some later point. It's possible to wrap `mpz_pow_ui` but it requires to have GMP allocate the buffer, and then copy it over into the final `ByteArray#`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 20:58:52 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 20:58:52 -0000 Subject: [GHC] #10770: Typeable solver has strange effects Message-ID: <051.c272986722d18d60205f4faa0b3da2dc@haskell.org> #10770: Typeable solver has strange effects -------------------------------------+------------------------------------- Reporter: | Owner: NeilMitchell | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Given: {{{#!hs import Data.Typeable main = print $ foo $ Just () foo :: Typeable (t a) => t a -> String foo x = let k = show $ typeOf x in k }}} I get: {{{ TypeableInfer.hs:7:24: Could not deduce (Typeable t) arising from a use of `typeOf' from the context (Typeable (t a)) bound by the type signature for foo :: Typeable (t a) => t a -> String at TypeableInfer.hs:6:8-38 In the second argument of `($)', namely `typeOf x' In the expression: show $ typeOf x In an equation for `k': k = show $ typeOf x }}} However, the error goes away with the minor modification of: {{{#!hs foo x = show $ typeOf x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 21:19:41 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 21:19:41 -0000 Subject: [GHC] #10770: Typeable solver has strange effects In-Reply-To: <051.c272986722d18d60205f4faa0b3da2dc@haskell.org> References: <051.c272986722d18d60205f4faa0b3da2dc@haskell.org> Message-ID: <066.9c5644d06f4e2a6e84daf106acad0cc7@haskell.org> #10770: Typeable solver has strange effects -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * cc: ekmett (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 21:28:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 21:28:24 -0000 Subject: [GHC] #10770: Typeable solver has strange effects In-Reply-To: <051.c272986722d18d60205f4faa0b3da2dc@haskell.org> References: <051.c272986722d18d60205f4faa0b3da2dc@haskell.org> Message-ID: <066.ff77f67382179f077d04a72665ee25c4@haskell.org> #10770: Typeable solver has strange effects -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Compiler (Type checker) Comment: I get the same error with HEAD (ghc-7.11.20150809), and also notice the following: {{{#!haskell {-# LANGUAGE FlexibleContexts #-} module Test where import Data.Typeable f :: (Typeable a, Typeable (Maybe a)) => Maybe a -> TypeRep f x = let k = typeOf x in k }}} shows the warning: {{{ Redundant constraint: Typeable (Maybe a) }}} Whereas the same program, with the last line changed to: {{{#!haskell f x = typeOf x }}} shows {{{ Redundant constraint: Typeable a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 21:32:47 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 21:32:47 -0000 Subject: [GHC] #10510: Testsuite driver does not run tests in parallel on Windows In-Reply-To: <045.f7051a2be634cd79e52b8850db4fc44f@haskell.org> References: <045.f7051a2be634cd79e52b8850db4fc44f@haskell.org> Message-ID: <060.d77a7da23bb7d3053384ee2984117cc2@haskell.org> #10510: Testsuite driver does not run tests in parallel on Windows -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Test Suite | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Phyx-): I have been trying to reproduce this ever since upgrading to Windows 10 but I don't seem to be able to. Can someone who has a Windows 8.1 or earlier machine check to see if this is still an issue? If so i'll install a VM and try to track it down now that I'm able to build the msys2 dll. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 23:42:20 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 23:42:20 -0000 Subject: [GHC] #10771: Installation of Ivory - Static flags have not been initialised Message-ID: <045.799f67bd688340da6719146f693d4e1e@haskell.org> #10771: Installation of Ivory - Static flags have not been initialised -------------------------------------+------------------------------------- Reporter: stiege | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Runtime crash (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Unfortunately I'm a Haskell newbie and can't provide very good detail for this report (I struggled to pass the Captcha!). However I will attach the output from a "make all" from the Ivory repository: https://github.com/GaloisInc/ivory.git Commit: '7ecea5839898b65430ca298fd1f3af4d2272e3fb'. Basically from what I can see, looks like it didn't work, output ends with: examples\Coroutine.hs:26:50: Warning: Unticked promoted constructor: `:->'. Use ':-> instead of `:->'. ghc.exe: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-mingw32): Static flags have not been initialised! Please call GHC.parseStaticFlags early enough. Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ghc.exe: warning: _tzset from msvcrt is linked instead of __imp__tzset -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 12 23:42:45 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Aug 2015 23:42:45 -0000 Subject: [GHC] #10771: Installation of Ivory - Static flags have not been initialised In-Reply-To: <045.799f67bd688340da6719146f693d4e1e@haskell.org> References: <045.799f67bd688340da6719146f693d4e1e@haskell.org> Message-ID: <060.f079aec92935de2e6d17bc9c4682c611@haskell.org> #10771: Installation of Ivory - Static flags have not been initialised -------------------------------------+------------------------------------- Reporter: stiege | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by stiege): * Attachment "makelog.log" added. Ivory build log -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 13 07:27:10 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Aug 2015 07:27:10 -0000 Subject: [GHC] #9993: PostfixOperators doesn't work for types In-Reply-To: <046.c7aa45b49c7f5a6d1b339ea2f860b5ae@haskell.org> References: <046.c7aa45b49c7f5a6d1b339ea2f860b5ae@haskell.org> Message-ID: <061.38728c21a946e98040bb362bd0f202c8@haskell.org> #9993: PostfixOperators doesn't work for types -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 13 07:29:19 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Aug 2015 07:29:19 -0000 Subject: [GHC] #10772: Type operator variable in prefix notation fails Message-ID: <046.ab9a1e8aa534bcd6d1b2f12748c0ce5a@haskell.org> #10772: Type operator variable in prefix notation fails -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Hi, I?m not sure if this is me misreading the documentation at https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/data-type- extensions.html#infix-tycons (in which case maybe the wording can be improved) or an actual bug. But I would have expected this code {{{ foo :: [(*)] -> Maybe (*) foo _ = Nothing }}} to be equivalent to {{{ foo :: [(*)] -> Maybe (*) foo _ = Nothing }}} at least with `-XNoTypeOperators`. But independent of that flag, with GHC HEAD and 7.8, I get {{{ /tmp/foo.hs:1:9: error: Not in scope: type constructor or class ?*? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 13 07:29:34 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Aug 2015 07:29:34 -0000 Subject: [GHC] #10772: Type operator variable in prefix notation fails In-Reply-To: <046.ab9a1e8aa534bcd6d1b2f12748c0ce5a@haskell.org> References: <046.ab9a1e8aa534bcd6d1b2f12748c0ce5a@haskell.org> Message-ID: <061.4849c29e7e5b0295b3bf9251cf634a13@haskell.org> #10772: Type operator variable in prefix notation fails -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by nomeata: Old description: > Hi, > > I?m not sure if this is me misreading the documentation at > https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/data- > type-extensions.html#infix-tycons (in which case maybe the wording can be > improved) or an actual bug. But I would have expected this code > > {{{ > foo :: [(*)] -> Maybe (*) > foo _ = Nothing > }}} > > to be equivalent to > > {{{ > foo :: [(*)] -> Maybe (*) > foo _ = Nothing > }}} > > at least with `-XNoTypeOperators`. But independent of that flag, with GHC > HEAD and 7.8, I get > {{{ > /tmp/foo.hs:1:9: error: Not in scope: type constructor or class ?*? > }}} New description: Hi, I?m not sure if this is me misreading the documentation at https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/data-type- extensions.html#infix-tycons (in which case maybe the wording can be improved) or an actual bug. But I would have expected this code {{{ foo :: [(*)] -> Maybe (*) foo _ = Nothing }}} to be equivalent to {{{ foo :: [a] -> Maybe a foo _ = Nothing }}} at least with `-XNoTypeOperators`. But independent of that flag, with GHC HEAD and 7.8, I get {{{ /tmp/foo.hs:1:9: error: Not in scope: type constructor or class ?*? }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 13 13:53:27 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Aug 2015 13:53:27 -0000 Subject: [GHC] #3712: Implement -dynamic-lib option In-Reply-To: <047.0ba626c454f1d59815233fb1be60c8e4@haskell.org> References: <047.0ba626c454f1d59815233fb1be60c8e4@haskell.org> Message-ID: <062.9cfe504d41299fb47a46005a59b2596d@haskell.org> #3712: Implement -dynamic-lib option -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: closed Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 6.12.1 RC1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => wontfix Comment: We probably don't need this; most people use Cabal which knows what to do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 13 13:56:16 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Aug 2015 13:56:16 -0000 Subject: [GHC] #9218: Upgrade the version of MinGW shipped with GHC In-Reply-To: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> References: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> Message-ID: <062.0de7fba511a8d1d4ab2bcd191a60148b@haskell.org> #9218: Upgrade the version of MinGW shipped with GHC -------------------------------------+------------------------------------- Reporter: komadori | Owner: gintas Type: task | Status: closed Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9014 | Blocking: 9215 Related Tickets: #3390 #10705 | Differential Revisions: Phab:D339 #10726 | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed Comment: Let's close this one as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 13 13:58:44 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Aug 2015 13:58:44 -0000 Subject: [GHC] #10768: Location information of LHsModule is incorrect In-Reply-To: <046.99b5a2d9e044c3653d6b967add4eb201@haskell.org> References: <046.99b5a2d9e044c3653d6b967add4eb201@haskell.org> Message-ID: <061.cecc21cf6e7a5e35b37daf6a1fe1e977@haskell.org> #10768: Location information of LHsModule is incorrect -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #597 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * cc: mpickering, alanz (added) * component: Compiler => Compiler (Parser) Comment: CC the parser experts. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 13 14:15:26 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Aug 2015 14:15:26 -0000 Subject: [GHC] #10768: Location information of LHsModule is incorrect In-Reply-To: <046.99b5a2d9e044c3653d6b967add4eb201@haskell.org> References: <046.99b5a2d9e044c3653d6b967add4eb201@haskell.org> Message-ID: <061.f93c6635331de5dd567b892afaf39f28@haskell.org> #10768: Location information of LHsModule is incorrect -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #597 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by alanz): I seem to recall questioning this when working on the API Annotations, and there was some reason. I think it had to do with using the parser to pick up the enabled extensions, and not wanting to force a load of the whole file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 13 14:18:32 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Aug 2015 14:18:32 -0000 Subject: [GHC] #10764: GHC panic (no skolem info) In-Reply-To: <045.2ad1583af708dd0797f9fcecf7a4e2e8@haskell.org> References: <045.2ad1583af708dd0797f9fcecf7a4e2e8@haskell.org> Message-ID: <060.e13585795d08451c6a133ae0764ee533@haskell.org> #10764: GHC panic (no skolem info) -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10045 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * component: Compiler => Compiler (Type checker) * related: => #10045 Comment: To reproduce, run `runhaskell bug.hs`, or add a `module Test where` to bug.hs first, and then call `ghc-7.10.2 bug.hs`. This looks like a duplicate of #10503, which is fixed in HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 13 16:36:43 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Aug 2015 16:36:43 -0000 Subject: [GHC] #9121: Presence of dyn_o files not checked upon recompilation In-Reply-To: <051.ef4d284e4c39d225b3b91119dd74ee0d@haskell.org> References: <051.ef4d284e4c39d225b3b91119dd74ee0d@haskell.org> Message-ID: <066.bbcd9a01cca5c6e5274025389f8ddf4e@haskell.org> #9121: Presence of dyn_o files not checked upon recompilation -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * priority: high => normal * component: Build System => Driver Comment: Does this only happen when you try to install Agda, or with other packages as well? A smaller test case to reproduce the bug would be great. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 13 16:42:17 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Aug 2015 16:42:17 -0000 Subject: [GHC] #7651: Buiding GHC with parallel IO manager freezes on Mac (not on FreeBSD) In-Reply-To: <052.b5316a423cedc87fa6cecb2672f617b3@haskell.org> References: <052.b5316a423cedc87fa6cecb2672f617b3@haskell.org> Message-ID: <067.6df818ba78991e332a1822051cf82039@haskell.org> #7651: Buiding GHC with parallel IO manager freezes on Mac (not on FreeBSD) -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.7 Resolution: worksforme | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * priority: high => normal * status: new => closed * resolution: => worksforme Comment: > I just build 7.10.2 rc with make -j5 and had no problems. Let's close this then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 13 19:05:37 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Aug 2015 19:05:37 -0000 Subject: [GHC] #9903: GHCi produces a cryptic message when using HPC In-Reply-To: <056.3163ec769e71b713310f29b6c2e4fa48@haskell.org> References: <056.3163ec769e71b713310f29b6c2e4fa48@haskell.org> Message-ID: <071.1fae3036a2e956489578c7a42b2cb825@haskell.org> #9903: GHCi produces a cryptic message when using HPC -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.9 Resolution: invalid | Keywords: hpc Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #9878, #9762 ? | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => invalid Comment: It appears that the issue here is really the poor error message. As noted in the User's Guide, hpc and GHCi aren't compatible (as the code generator is expected to produce some symbols which the interpreter does not produce, hence the error message here). I'll push a fix for the error message shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 13 19:05:54 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Aug 2015 19:05:54 -0000 Subject: [GHC] #9903: GHCi produces a cryptic message when using HPC In-Reply-To: <056.3163ec769e71b713310f29b6c2e4fa48@haskell.org> References: <056.3163ec769e71b713310f29b6c2e4fa48@haskell.org> Message-ID: <071.ef75162be4478edffe374afc34567bc3@haskell.org> #9903: GHCi produces a cryptic message when using HPC -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.9 Resolution: invalid | Keywords: hpc Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #9878, #9762 ? | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d2dd5af433be80464883735f133f3e4dea9c8bd4/ghc" d2dd5af/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d2dd5af433be80464883735f133f3e4dea9c8bd4" DynFlags: Prohibit hpc and byte-code interpreter The user's guide says hpc is incompatible with GHCi and #9903 would agree. Fixes #9903. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 13 19:05:54 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Aug 2015 19:05:54 -0000 Subject: [GHC] #10769: Yet another crash from typed holes In-Reply-To: <049.adcd25e8757381b099d00f18d1417d8a@haskell.org> References: <049.adcd25e8757381b099d00f18d1417d8a@haskell.org> Message-ID: <064.60b2b3cb39ac11879c7601182b383659@haskell.org> #10769: Yet another crash from typed holes -------------------------------+----------------------------------------- Reporter: rpglover64 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by Ben Gamari ): In [changeset:"ec68618bac918f365a7760062eb351cba3e4ddb3/ghc" ec68618b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ec68618bac918f365a7760062eb351cba3e4ddb3" Name: Show NameSort in warning This is quite useful information to know. Spotted when looking at #10769. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 13 23:03:28 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Aug 2015 23:03:28 -0000 Subject: [GHC] #9121: Presence of dyn_o files not checked upon recompilation In-Reply-To: <051.ef4d284e4c39d225b3b91119dd74ee0d@haskell.org> References: <051.ef4d284e4c39d225b3b91119dd74ee0d@haskell.org> Message-ID: <066.378fc7c37476d2c07cc63c73077e2efe@haskell.org> #9121: Presence of dyn_o files not checked upon recompilation -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): I definitely can believe that this can happen, because I'm pretty sure the recompilation checker only checks o files (and not dyn_o files). Easy test case: {{{ ghc --make A.hs -dynamic-too rm A.dyn_o ghc --make A.hs -dynamic-too }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 13 23:15:05 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Aug 2015 23:15:05 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.c532b18d0dbdfb6137b2c3b3bf4e7af3@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8226, #8745 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by oerjan): * cc: oerjan (added) * related: 8226, 8745 => #8226, #8745 Comment: It seems to me that there have been several competing goals mentioned here. However, I do not think they are impossible to mostly satisfy simultaneously, except perhaps for simplicity of the design. (In particular, I think it requires reinstating the constructor check.) 1. Code that is ''not'' annotated with roles should still largely enjoy the same module encapsulation as in H2010, so that module writers do not need to consider the implications of `coerce` or GND if they are not actually using them. With Safe Haskell, `coerce` and GND should not be able to create code based on such a module that couldn't be written "by hand". 2. Even without role annotations, `coerce` and GND should still be possible to use in Safe Haskell for most code that ''can'' be written by hand. (Preferrably as much as today without Safe Haskell enabled). 3. Safe Haskell should be inferrable without changing the semantics of a module. 4. Exporting all the constructors of a type from an `Unsafe` "`Internal`" module should not prevent data encapsulation by not reexporting them from a `Trustworthy` one. 5. Explicit role annotations, when used, should overrule all automatic restrictions on `Safe` mode, since that means the author has explicitly stated their intent. Point 1 means that it is not ideal to make roles default to `representational` with no further checks. Point 2 means, similarly, that it is not ideal to make `nominal` the default. Point 4 means that any constructor export check cannot just be done by looking at the module defining the type. Given this, I ''hope'' the following is compatible with all the goals above: * Default inferred role remains `representational`. * Any use of `coerce` (including via GND) must respect roles etc. as currently without Safe Haskell. * If allowed in general, a "lifting" use of `coerce` is compatible with `Safe` if ''either'': * The type has an explicit role annotation, ''or'' * All of the type's data constructors are in scope. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 14 02:23:49 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Aug 2015 02:23:49 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.301221eaa58208b061521b99f51052fe@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8226, #8745 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:39 oerjan]: > Given this, I ''hope'' the following is compatible with all the goals above: > > * Default inferred role remains `representational`. > * Any use of `coerce` (including via GND) must respect roles etc. as currently without Safe Haskell. > * If allowed in general, a "lifting" use of `coerce` is compatible with `Safe` if ''either'': > * The type has an explicit role annotation, ''or'' > * All of the type's data constructors are in scope. For this to work out, the last check above must be recursive, looking at all datatypes mentioned in those in-scope data constructors, out to the leaves. Otherwise, a programmer could write a trivial wrapper around a type; all the data constructors would be in scope for the wrapper, and then the programmer could `coerce` away. It's the recursiveness of this check that's annoying. Another (small) problem with this is that it means redundant role annotations are no longer a no-op. For example: {{{ data Maybe1 a = Just1 a | Nothing1 data Maybe2 a = Just2 a | Nothing2 type role Maybe2 representational }}} `Maybe1` and `Maybe2` will have subtly different behavior with respect to Safe Haskell under this proposal. And just because the author of `Maybe2` wanted to add some documentation about roles, much like most programmers add easy-to-infer type signatures. I don't think the point I'm making should kill this proposal, but it is a downside. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 14 02:34:59 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Aug 2015 02:34:59 -0000 Subject: [GHC] #10772: Type operator variable in prefix notation fails In-Reply-To: <046.ab9a1e8aa534bcd6d1b2f12748c0ce5a@haskell.org> References: <046.ab9a1e8aa534bcd6d1b2f12748c0ce5a@haskell.org> Message-ID: <061.792398fad9538d426088f73493b88d08@haskell.org> #10772: Type operator variable in prefix notation fails -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * component: Compiler (Parser) => Documentation Comment: This is an error in the manual. The first bullet should read: A type constructor or class can be any non-reserved operator. Symbols used in types are always type constructors or classes, never variables. Note that this is different from the lexical syntax of data constructors, which are required to begin with a `:`. The behavior changed somewhat recently. (7.6?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 14 03:21:27 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Aug 2015 03:21:27 -0000 Subject: [GHC] #10754: truncate /= double2Int In-Reply-To: <043.90ddeb54230f66037ee120962cf0eb95@haskell.org> References: <043.90ddeb54230f66037ee120962cf0eb95@haskell.org> Message-ID: <058.6337bbc96ec64b64ce20c8a4f762977b@haskell.org> #10754: truncate /= double2Int -------------------------------------+------------------------------------- Reporter: cblp | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: duplicate | Keywords: truncate, | double2Int, rewrite, rule Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => duplicate Comment: Essentially a duplicate of #3070. Feel free to continue the discussion there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 14 05:29:24 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Aug 2015 05:29:24 -0000 Subject: [GHC] #10754: truncate /= double2Int In-Reply-To: <043.90ddeb54230f66037ee120962cf0eb95@haskell.org> References: <043.90ddeb54230f66037ee120962cf0eb95@haskell.org> Message-ID: <058.92bbe5095a2e071aeaba21440dc621af@haskell.org> #10754: truncate /= double2Int -------------------------------------+------------------------------------- Reporter: cblp | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: duplicate | Keywords: truncate, | double2Int, rewrite, rule Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by cblp): rwbarton, I don't consider this a duplicate of #3070. That is about the value of NaN, but this is about consistency-breaking optimization. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 14 06:28:34 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Aug 2015 06:28:34 -0000 Subject: [GHC] #10754: truncate /= double2Int In-Reply-To: <043.90ddeb54230f66037ee120962cf0eb95@haskell.org> References: <043.90ddeb54230f66037ee120962cf0eb95@haskell.org> Message-ID: <058.b8828eedcaa929012ae733ca9329bb8b@haskell.org> #10754: truncate /= double2Int -------------------------------------+------------------------------------- Reporter: cblp | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: duplicate | Keywords: truncate, | double2Int, rewrite, rule Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): While not exactly identical, the issues here and in #3070 are so closely related that any attempt to address one should also take the other into consideration. So, it's more helpful if the discussion is consolidated into one ticket thread. Certainly we would not give up the rule `truncate = double2Int` simply because the two sides give different nonsense outputs for the same nonsense input. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 14 08:52:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Aug 2015 08:52:01 -0000 Subject: [GHC] #3070: floor(0/0) should not be defined In-Reply-To: <046.e7310ec88130e4aef68644b0cf077a3b@haskell.org> References: <046.e7310ec88130e4aef68644b0cf077a3b@haskell.org> Message-ID: <061.081a6b8152089bc0aea41bf3d11d7611@haskell.org> #3070: floor(0/0) should not be defined -------------------------------------+------------------------------------- Reporter: carette | Owner: squadette Type: bug | Status: new Priority: lowest | Milestone: 7.12.1 Component: Prelude | Version: 6.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9276 | Blocking: Related Tickets: #10754 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * related: => #10754 Comment: See also #10754. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 14 09:24:35 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Aug 2015 09:24:35 -0000 Subject: [GHC] #3070: floor(0/0) should not be defined In-Reply-To: <046.e7310ec88130e4aef68644b0cf077a3b@haskell.org> References: <046.e7310ec88130e4aef68644b0cf077a3b@haskell.org> Message-ID: <061.2f9e97c4927495552a01951c7088fc79@haskell.org> #3070: floor(0/0) should not be defined -------------------------------------+------------------------------------- Reporter: carette | Owner: squadette Type: bug | Status: new Priority: lowest | Milestone: 7.12.1 Component: Prelude | Version: 6.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9276 | Blocking: Related Tickets: #10754 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): While this doesn't really address the crux of the problem, one option here would be to introduce another pair of floating point types which ensure proper treatment of all IEEE 754 constructs at the expense of performance. I really don't like the fact that this would make you choose between correctness and speed (especially since arguably the default should be correctness), but it is (I think) an option on the table. As far as I can tell, this could be strictly a library change (with the types wrapping the unboxed `Float#` and `Double#` types; we would just need to double-check that the constant folding rules in GHC are correct with respect to the special floating-point values). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 14 17:11:16 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Aug 2015 17:11:16 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.1b61f4b69ca1b34ae504b8a0b801c1ec@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8226, #8745 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by oerjan): Replying to [comment:40 goldfire]: > For this to work out, the last check above must be recursive, looking at all datatypes mentioned in those in-scope data constructors, out to the leaves. Otherwise, a programmer could write a trivial wrapper around a type; all the data constructors would be in scope for the wrapper, and then the programmer could `coerce` away. It's the recursiveness of this check that's annoying. Oops. What's worse, this interacts with role annotations: {{{ module A (A) where -- inferred type role A representable data A a = A' a ... {-# LANGUAGE Safe #-} module B where import A type role B representative newtype B b = B (A b) }}} By my literal proposal above, module `B` has just managed to achieve such a wrapper, just with a role annotation and ''without'' `A'` in scope. Which means my point 5 is unsupportable as given, and the closest option I can think of requires tracking `Coercible` separately from roles - `B` here should have the role given, since that's the inferred one, but it should ''not'' therefore automatically be `Coercible` to `A`, except where `A'` is in scope. Or wait, hm. Perhaps a simpler option might be to distinguish `representable` from `inferredRepresentable` (better name hereby solicited), and have the rule that `inferredRepresentable` can be treated as `representable` only when all necessary constructors are in scope, recursively until you reach a non-`inferred` role. (Similarly for `phantom`, I guess.) That makes the role annotation for `B` wrong because `A`'s role is `inferredRepresentable`, and `A'` is not in scope. Also, there should then probably be a pragma to automatically remove the "inferred" when possible for types declared in a module. Warning: the above was written in a bit of a hurry. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 15 01:36:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Aug 2015 01:36:10 -0000 Subject: [GHC] #10773: Add Control.Monad.IO.Class from transformers to base Message-ID: <050.fa78270471b5c8a35c327e5b8e6838d1@haskell.org> #10773: Add Control.Monad.IO.Class from transformers to base -------------------------------------+------------------------------------- Reporter: | Owner: ekmett RyanGlScott | Type: feature | Status: new request | Priority: normal | Milestone: Component: Core | Version: 7.10.2 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- (As proposed in a Haskell libraries mailing list thread [https://mail.haskell.org/pipermail/libraries/2015-July/026008.html here]). This Trac issue addresses one of the two suggestions made in the proposal, i.e., moving `Control.Monad.IO.Class` from `transformers` to `base`. (The second, introducing a `MonadIO Q` instance in `template-haskell`, can be dealt with depending on the result of this.) Conceptually, this change is very similar in spirit to #9664?the `MonadIO` class is a Haskell98 typeclass that has proven to be widely useful in abstracting `IO`-based functions into a type signature that can be used with monad transformer stacks. Moving `MonadIO`'s module into `base` would allow more widespread use without incurring a `transformers` dependency, and it could provide a first step for generalizing more `base` functions from `IO` to `MonadIO`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 15 01:46:03 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Aug 2015 01:46:03 -0000 Subject: [GHC] #10773: Add Control.Monad.IO.Class from transformers to base In-Reply-To: <050.fa78270471b5c8a35c327e5b8e6838d1@haskell.org> References: <050.fa78270471b5c8a35c327e5b8e6838d1@haskell.org> Message-ID: <065.5490ee9658531987163714c2b7685d81@haskell.org> #10773: Add Control.Monad.IO.Class from transformers to base -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1147 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: => Phab:D1147 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 15 08:01:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Aug 2015 08:01:37 -0000 Subject: [GHC] #10755: Add `MonadPlus IO` and `Alternative IO` instances In-Reply-To: <042.9475d11a3f91fa4e741f69ce0a266155@haskell.org> References: <042.9475d11a3f91fa4e741f69ce0a266155@haskell.org> Message-ID: <057.a9cb5e2c704bc14a90a88ef89e5ae1fa@haskell.org> #10755: Add `MonadPlus IO` and `Alternative IO` instances -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: Resolution: | Keywords: report- | impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1148 -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch * differential: => Phab:D1148 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 15 08:13:47 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Aug 2015 08:13:47 -0000 Subject: [GHC] #10773: Add Control.Monad.IO.Class from transformers to base In-Reply-To: <050.fa78270471b5c8a35c327e5b8e6838d1@haskell.org> References: <050.fa78270471b5c8a35c327e5b8e6838d1@haskell.org> Message-ID: <065.d584cfb467a0a78e70d096d0be21fcb7@haskell.org> #10773: Add Control.Monad.IO.Class from transformers to base -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: ekmett Type: feature request | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1147 -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 15 08:23:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Aug 2015 08:23:24 -0000 Subject: [GHC] #10774: Use `Natural` rather than `Integer` in `GHC.TypeLits` Message-ID: <042.7c7cb988b2d1af2ee71900558e4a13e4@haskell.org> #10774: Use `Natural` rather than `Integer` in `GHC.TypeLits` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: | Version: 7.10.2 libraries/base | Keywords: TypeLits | Operating System: Unknown/Multiple Natural | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When the numeric type-literals were implement via `GHC.TypeLits` there was no `Natural` type in `base` yet. But since GHC 7.10 we finally have `Natural` available in base! Specifically, the following 3 type-signatures in `GHC.TypeLits` cpmtaom `Integer` that ought rather be `Natural`s: {{{#!hs someNatVal :: Integer -> Maybe SomeNat natVal :: forall n proxy. KnownNat n => proxy n -> Integer natVal' :: forall n. KnownNat n => Proxy# n -> Integer }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 15 08:23:53 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Aug 2015 08:23:53 -0000 Subject: [GHC] #10774: Use `Natural` rather than `Integer` in `GHC.TypeLits` In-Reply-To: <042.7c7cb988b2d1af2ee71900558e4a13e4@haskell.org> References: <042.7c7cb988b2d1af2ee71900558e4a13e4@haskell.org> Message-ID: <057.089f98660e9a844a53b99eb4885509e2@haskell.org> #10774: Use `Natural` rather than `Integer` in `GHC.TypeLits` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: TypeLits | Natural Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by hvr: Old description: > When the numeric type-literals were implement via `GHC.TypeLits` there > was no `Natural` type in `base` yet. But since GHC 7.10 we finally have > `Natural` available in base! > > Specifically, the following 3 type-signatures in `GHC.TypeLits` cpmtaom > `Integer` that ought rather be `Natural`s: > > {{{#!hs > someNatVal :: Integer -> Maybe SomeNat > > natVal :: forall n proxy. KnownNat n => proxy n -> Integer > > natVal' :: forall n. KnownNat n => Proxy# n -> Integer > }}} New description: When the numeric type-literals were implement via `GHC.TypeLits` there was no `Natural` type in `base` yet. But since GHC 7.10 we finally have `Natural` available in base! Specifically, the following 3 type-signatures in `GHC.TypeLits` contain `Integer`s that ought rather be `Natural`s: {{{#!hs someNatVal :: Integer -> Maybe SomeNat natVal :: forall n proxy. KnownNat n => proxy n -> Integer natVal' :: forall n. KnownNat n => Proxy# n -> Integer }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 15 09:09:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Aug 2015 09:09:49 -0000 Subject: [GHC] #9381: Implement -rdynamic In-Reply-To: <056.1019797b6ed554879c40e702f4d5c1f2@haskell.org> References: <056.1019797b6ed554879c40e702f4d5c1f2@haskell.org> Message-ID: <071.f9f9ddc7a2eadde5f8d95d92d87c3a0b@haskell.org> #9381: Implement -rdynamic -------------------------------------+------------------------------------- Reporter: | Owner: Phyx- facundo.dominguez | Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7015 | Differential Revisions: Phab:D102 -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: => Phyx- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 15 09:10:13 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Aug 2015 09:10:13 -0000 Subject: [GHC] #9381: Implement -rdynamic In-Reply-To: <056.1019797b6ed554879c40e702f4d5c1f2@haskell.org> References: <056.1019797b6ed554879c40e702f4d5c1f2@haskell.org> Message-ID: <071.0aab33b57a304813d0274337ae739776@haskell.org> #9381: Implement -rdynamic -------------------------------------+------------------------------------- Reporter: | Owner: Phyx- facundo.dominguez | Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7015 | Differential Revisions: Phab:D102 -------------------------------------+------------------------------------- Changes (by Phyx-): * milestone: 7.10.1 => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 15 09:44:13 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Aug 2015 09:44:13 -0000 Subject: [GHC] #9381: Implement -rdynamic In-Reply-To: <056.1019797b6ed554879c40e702f4d5c1f2@haskell.org> References: <056.1019797b6ed554879c40e702f4d5c1f2@haskell.org> Message-ID: <071.9ea012708f3905292856776df6e8ab8c@haskell.org> #9381: Implement -rdynamic -------------------------------------+------------------------------------- Reporter: | Owner: Phyx- facundo.dominguez | Type: feature request | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7015 | Differential Revisions: Phab:D1149 -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: Phab:D102 => Phab:D1149 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 15 11:45:53 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Aug 2015 11:45:53 -0000 Subject: [GHC] #10744: Allow oneShot to work with unboxed types In-Reply-To: <043.1a18f79737236ccee17a4841dc4bdcd8@haskell.org> References: <043.1a18f79737236ccee17a4841dc4bdcd8@haskell.org> Message-ID: <058.a415998e32fde8d1e7429555b3d06586@haskell.org> #10744: Allow oneShot to work with unboxed types -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1136 -------------------------------------+------------------------------------- Comment (by akio): Thank you very much for implementing this! Replying to [comment:13 nomeata]: > Voila, akio. Hack away! And let me know if `oneShot` makes a difference for your use case, I?d like to report on it in my thesis, which marginally mentions `oneShot` as well. In one of my benchmarks (serializing JSON), `oneShot` improves performance by 50%. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 15 14:20:27 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Aug 2015 14:20:27 -0000 Subject: [GHC] #10755: Add `MonadPlus IO` and `Alternative IO` instances In-Reply-To: <042.9475d11a3f91fa4e741f69ce0a266155@haskell.org> References: <042.9475d11a3f91fa4e741f69ce0a266155@haskell.org> Message-ID: <057.0ccf22c3668600a112bddcd7273e6646@haskell.org> #10755: Add `MonadPlus IO` and `Alternative IO` instances -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: Resolution: | Keywords: report- | impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1148 -------------------------------------+------------------------------------- Comment (by RyanGlScott): Note that the [http://hub.darcs.net/ross/transformers/patch/4af2ebe00671e3e20c5ce8edde8027a9bd0cd187 upstream version] of `transformers` has already removed these orphan instances. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 15 15:27:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Aug 2015 15:27:19 -0000 Subject: [GHC] #7325: threadDelay mistreats minBound and maxBound in some configurations In-Reply-To: <048.f6376e5e233d59dcc7fd251637dbe84b@haskell.org> References: <048.f6376e5e233d59dcc7fd251637dbe84b@haskell.org> Message-ID: <063.fdbca5a878c44306c81d504650d13692@haskell.org> #7325: threadDelay mistreats minBound and maxBound in some configurations -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Runtime System | Version: 7.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | base/tests/T8089 Blocked By: | Blocking: Related Tickets: #9722 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"185719158137b0cdba32b32e8a8fda8eb6321215/ghc" 1857191/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="185719158137b0cdba32b32e8a8fda8eb6321215" Testsuite: mark T8089 expect_broken(#7325) on Windows }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 15 15:27:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Aug 2015 15:27:19 -0000 Subject: [GHC] #10623: Handling of ASCII encodings introduced in D898 breaks Unicode terminal detection In-Reply-To: <046.3a764cfd54e5a4e4443ef4864c8fddbf@haskell.org> References: <046.3a764cfd54e5a4e4443ef4864c8fddbf@haskell.org> Message-ID: <061.469b27edf26fea0320620acd38190a87@haskell.org> #10623: Handling of ASCII encodings introduced in D898 breaks Unicode terminal detection -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T8958a Blocked By: | Blocking: Related Tickets: #10298, #7695 | Differential Revisions: | Phab:D1059, Phab:D1085 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"89060374ea0242bc2d38425ba63f33b5189325b4/ghc" 89060374/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="89060374ea0242bc2d38425ba63f33b5189325b4" Testsuite: mark encoding005 expect_broken(#10623) on Windows }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 15 15:32:13 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Aug 2015 15:32:13 -0000 Subject: [GHC] #10623: Handling of ASCII encodings introduced in D898 breaks Unicode terminal detection In-Reply-To: <046.3a764cfd54e5a4e4443ef4864c8fddbf@haskell.org> References: <046.3a764cfd54e5a4e4443ef4864c8fddbf@haskell.org> Message-ID: <061.85101e19468369c84b521bd2e652f8b4@haskell.org> #10623: Handling of ASCII encodings introduced in D898 breaks Unicode terminal detection -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T8958a Blocked By: | Blocking: Related Tickets: #10298, #7695 | Differential Revisions: | Phab:D1059, Phab:D1085 -------------------------------------+------------------------------------- Changes (by thomie): * status: closed => new * resolution: fixed => * os: Unknown/Multiple => Windows Comment: The test `encoding005` is failing on Windows with an unknown ASCII encoding error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 15 19:51:55 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Aug 2015 19:51:55 -0000 Subject: [GHC] #9614: ghc --print-(gcc|ld)-linker-flags broken In-Reply-To: <047.8a05a0d53d11d93a9d7fdc38579c7742@haskell.org> References: <047.8a05a0d53d11d93a9d7fdc38579c7742@haskell.org> Message-ID: <062.200be3b9bb1a55c5006ba29d4558c797@haskell.org> #9614: ghc --print-(gcc|ld)-linker-flags broken -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 9421 Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by fabiool): I've also faced this issue. Would be nice to have it fixed sooner. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 15 20:21:59 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Aug 2015 20:21:59 -0000 Subject: [GHC] #10775: Enable PolyKinds in GHC.Generics Message-ID: <050.1fb49e8a4f9e9ff5b73b6dbae85f944e@haskell.org> #10775: Enable PolyKinds in GHC.Generics -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 7.10.2 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- As suggested in [https://mail.haskell.org/pipermail/libraries/2015-July/025981.html this] Haskell libraries mailing list thread. Among other benefits, this would allow use of generic functions with `Proxy t` when `t` is of a kind other than `*`. There seem to be more changes required than just putting `{-# LANGUAGE PolyKinds #-}` in `GHC.Generics`, however, since I tried doing that myself and found myself unable to properly derive `Generic(1)` instances in `GHC.Generics`. Here is a snippet of the resulting error message: {{{ libraries/base/GHC/Generics.hs:826:1: error: Couldn't match type ?M1 i0 c0 (M1 i1 c1 U1) p0? with ?M1 D x? Expected type: Rep (Proxy t) x Actual type: M1 i0 c0 (M1 i1 c1 U1) p0 Relevant bindings include from :: Proxy t -> Rep (Proxy t) x (bound at libraries/base/GHC/Generics.hs:826:1) In the expression: M1 (M1 U1) In an equation for ?from?: from Proxy = M1 (M1 U1) When typechecking the code for ?from? in a derived instance for ?Generic (Proxy t)?: To see the code I am typechecking, use -ddump-deriv libraries/base/GHC/Generics.hs:826:1: error: Couldn't match type ?M1 t0 t1 (M1 t3 t4 U1) t2? with ?M1 D x? Expected type: Rep (Proxy t) x Actual type: M1 t0 t1 (M1 t3 t4 U1) t2 Relevant bindings include to :: Rep (Proxy t) x -> Proxy t (bound at libraries/base/GHC/Generics.hs:826:1) In the pattern: M1 (M1 U1) In an equation for ?to?: to (M1 (M1 U1)) = Proxy When typechecking the code for ?to? in a derived instance for ?Generic (Proxy t)?: To see the code I am typechecking, use -ddump-deriv In the instance declaration for ?Generic (Proxy t)? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 15 20:30:38 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Aug 2015 20:30:38 -0000 Subject: [GHC] #9121: Presence of dyn_o files not checked upon recompilation In-Reply-To: <051.ef4d284e4c39d225b3b91119dd74ee0d@haskell.org> References: <051.ef4d284e4c39d225b3b91119dd74ee0d@haskell.org> Message-ID: <066.27f9ed8d2659235c84039f34f3dc24e5@haskell.org> #9121: Presence of dyn_o files not checked upon recompilation -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): Also, easy workaround: delete the offending `.o` file and GHC will recompile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 15 21:45:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Aug 2015 21:45:57 -0000 Subject: [GHC] #10755: Add `MonadPlus IO` and `Alternative IO` instances In-Reply-To: <042.9475d11a3f91fa4e741f69ce0a266155@haskell.org> References: <042.9475d11a3f91fa4e741f69ce0a266155@haskell.org> Message-ID: <057.0ed84c774d055c1da14ad44ea5ec901d@haskell.org> #10755: Add `MonadPlus IO` and `Alternative IO` instances -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: Resolution: | Keywords: report- | impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1148 -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:2 RyanGlScott]: > Note that the [http://hub.darcs.net/ross/transformers/patch/4af2ebe00671e3e20c5ce8edde8027a9bd0cd187 upstream version] of `transformers` has already removed these orphan instances. Oh, didn't notice... however that implies a major version bump for the next `transformer`s package. It'd better if `transformers` kept providing those orphan instances to smooth over the transition for already released package versions... let's hope this doesn't affect too many... :-/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 15 22:05:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Aug 2015 22:05:41 -0000 Subject: [GHC] #10755: Add `MonadPlus IO` and `Alternative IO` instances In-Reply-To: <042.9475d11a3f91fa4e741f69ce0a266155@haskell.org> References: <042.9475d11a3f91fa4e741f69ce0a266155@haskell.org> Message-ID: <057.6e461ebf9dc25f5d5cd0a97c9c54375f@haskell.org> #10755: Add `MonadPlus IO` and `Alternative IO` instances -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: Resolution: | Keywords: report- | impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1148 -------------------------------------+------------------------------------- Comment (by RyanGlScott): If removing them from `transformers` causes too much heartburn, I'd be fine with asking Ross to put them back. My rationale when making that pull request was that putting orphan `IO` instances in a library about monad transformers didn't make much sense, and probably belong somewhere like `base-orphans` instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 15 22:51:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Aug 2015 22:51:29 -0000 Subject: [GHC] #10549: floatExpr tick break<2> In-Reply-To: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> References: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> Message-ID: <066.8a5855a62729cb2b3036cefafa2d0a6b@haskell.org> #10549: floatExpr tick break<2> -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: bgamari Type: bug | Status: merge Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T10549 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1128 -------------------------------------+------------------------------------- Comment (by nomeata): As Debian is moving to GHC-7.10, this is affecting us. So if someone would do the merge (which is not automatic) soon, that would be appreciated, as we would include that patch in our 7.10.2 package. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 16 01:32:23 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Aug 2015 01:32:23 -0000 Subject: [GHC] #10677: slightly silly assembly for testing whether a Word# is 0## In-Reply-To: <047.666ef36ac1cc91ac56611c092c7fbb22@haskell.org> References: <047.666ef36ac1cc91ac56611c092c7fbb22@haskell.org> Message-ID: <062.f57bc8ce10721c0c8809f06853914714@haskell.org> #10677: slightly silly assembly for testing whether a Word# is 0## -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10750 | Differential Revisions: Phab:D1137 -------------------------------------+------------------------------------- Comment (by rwbarton): I would guess so. Maybe worth further investigation though. Another possible cause is #8279. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 16 11:08:03 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Aug 2015 11:08:03 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.e9ef2311b11b0a5b45a617a33ba77d4e@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by slyfox): Done the following: - patched GHC [1] to print only blackholes in '+RTS -Da' and hide unresolvable addresses as [addr] - extended blackhole printer to dump '->indirectee' contents as a heap object (is it safe?) - added synchronization to printClosure to save stderr from multiple threads - linked ghc-stage2 with debug runtime - ran as '-j8 +RTS -A128M -Da' - sorted output by most frequent calls ('sort l | uniq -c | sort -n -k1 -r | head -n30') Here is the result: {{{ 4179540 BLACKHOLE(Object [addr] = ghc-prim:GHC.Types.I#([addr])\n)\n 2031781 BLACKHOLE(Object [addr] = ghc:CLabel.IdLabel([addr], [addr], [addr])\n)\n 1782769 BLACKHOLE(Object [addr] = FUN/1() )\n 911023 BLACKHOLE(Object [addr] = FUN/1(, [addr]) )\n 474894 BLACKHOLE(Object [addr] = ghc:TypeRep.TyConApp([addr], [addr])\n)\n 380862 BLACKHOLE(Object [addr] = FUN/2() )\n 370195 BLACKHOLE(Object [addr] = ghc-prim:GHC.Tuple.(,,)([addr], [addr], [addr])\n)\n 352184 BLACKHOLE(Object [addr] = PAP/2([addr], [addr])\n)\n 282341 BLACKHOLE(Object [addr] = ghc:Var.Id([addr], [addr], , [addr], [addr], [addr])\n)\n 190979 BLACKHOLE(Object [addr] = ghc:X86.Instr.JMP([addr], [addr])\n)\n 189194 BLACKHOLE(Object [addr] = ghc:X86.Instr.JXX([addr], [addr])\n)\n 176401 BLACKHOLE(Object [addr] = ghc:Unique.MkUnique([addr])\n)\n 130071 BLACKHOLE(Object [addr] = PAP/1([addr], [addr])\n)\n 127332 BLACKHOLE(Object [addr] = ghc:VarEnv.InScope([addr], [addr])\n)\n 121511 BLACKHOLE(Object [addr] = ghc:TypeRep.FunTy([addr], [addr])\n)\n 118142 BLACKHOLE(Object [addr] = FUN/1() )\n 106457 BLACKHOLE(Object [addr] = ghc:StgCmmMonad.HeapUsage([addr], [addr])\n)\n 84274 BLACKHOLE(Object [addr] = 0tT640fErehCGZtZRn6YbE:Data.Map.Base.Bin([addr], [addr], [addr], [addr], [addr])\n)\n 83945 BLACKHOLE(Object [addr] = ghc:Module.Module([addr], [addr])\n)\n 71331 BLACKHOLE(Object [addr] = ghc:TrieMap.SingletonMap([addr], [addr])\n)\n 69775 BLACKHOLE(Object [addr] = ghc:StgCmmClosure.LFThunk([addr], [addr], [addr], [addr], [addr])\n)\n 69754 BLACKHOLE(Object [addr] = FUN/2(, [addr], [addr]) )\n 69396 BLACKHOLE(Object [addr] = 0tT640fErehCGZtZRn6YbE:Data.IntMap.Base.Tip([addr], [addr])\n)\n 66129 BLACKHOLE(Object [addr] = 0tT640fErehCGZtZRn6YbE:Data.IntMap.Base.Nil()\n)\n 58339 BLACKHOLE(Object [addr] = ghc:HsPat.ConPatOut([addr], [addr], [addr], [addr], , [addr], [addr])\n)\n 55027 BLACKHOLE(Object [addr] = FUN/1() )\n 53318 BLACKHOLE(Object [addr] = ghc:Var.Id([addr], [addr], [addr], [addr], [addr], [addr])\n)\n 53142 BLACKHOLE(Object [addr] = FUN/2(, [addr]) )\n 53057 BLACKHOLE(Object [addr] = FUN/2() )\n 34197 BLACKHOLE(Object [addr] = ghc:Name.Name([addr], [addr], [addr], [addr])\n)\n }}} Is it expected to see I# here? small part of BLACKHOLE patch [1]: {{{#!diff @@ -221,7 +223,7 @@ printClosure( StgClosure *obj ) case BLACKHOLE: debugBelch("BLACKHOLE("); - printPtr((StgPtr)((StgInd*)obj)->indirectee); - debugBelch(")\n"); + printObj((StgPtr)((StgInd*)obj)->indirectee); + debugBelch(")\\n"); break; }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 16 12:38:54 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Aug 2015 12:38:54 -0000 Subject: [GHC] #10549: floatExpr tick break<2> In-Reply-To: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> References: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> Message-ID: <066.aa6f411d5a0773d6c5d3b697602a476d@haskell.org> #10549: floatExpr tick break<2> -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T10549 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1128 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: nomeata, your wish is my command. I've merged this with 5af80e79b0b679565ffcfae8ed34188561ef1452 and 75fd8747c128c3f946769510ce8cfe089821116d. Sorry about the two commits; I pushed a bit before noticing some testsuite failures. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 16 12:42:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Aug 2015 12:42:45 -0000 Subject: [GHC] #10549: floatExpr tick break<2> In-Reply-To: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> References: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> Message-ID: <066.39bdcaba6fd626d3d325982f60f93c4e@haskell.org> #10549: floatExpr tick break<2> -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T10549 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1128 -------------------------------------+------------------------------------- Comment (by nomeata): Thanks! Debian upload on its way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 16 12:48:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Aug 2015 12:48:22 -0000 Subject: [GHC] #10775: Enable PolyKinds in GHC.Generics In-Reply-To: <050.1fb49e8a4f9e9ff5b73b6dbae85f944e@haskell.org> References: <050.1fb49e8a4f9e9ff5b73b6dbae85f944e@haskell.org> Message-ID: <065.c0c5d4bff452099329909ece71c2b20c@haskell.org> #10775: Enable PolyKinds in GHC.Generics -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dreixel): I'm not entirely sure what's the goal here. To make `Generic1 :: k -> *` instead of its current `Generic1 :: * -> *` kind? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 16 14:12:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Aug 2015 14:12:32 -0000 Subject: [GHC] #10775: Enable PolyKinds in GHC.Generics In-Reply-To: <050.1fb49e8a4f9e9ff5b73b6dbae85f944e@haskell.org> References: <050.1fb49e8a4f9e9ff5b73b6dbae85f944e@haskell.org> Message-ID: <065.4c8b5e39193a56a377a30f49b0c80707@haskell.org> #10775: Enable PolyKinds in GHC.Generics -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by RyanGlScott): > To make `Generic1 :: k -> *` instead of its current `Generic1 :: * -> *` kind? No, my main motivation involves `Proxy` from `Data.Proxy`. Currently, `Proxy` is defined like so: {{{#!hs data Proxy (t :: k) = Proxy }}} using `PolyKinds`, but `Proxy` has a `Generic` instance defined in `GHC.Generics`, a module which doesn't have `PolyKinds` enabled. As a result, the resulting `Generic` instance is {{{#!hs instance Generic (Proxy (t :: *)) }}} This prevents you from using certain `Proxy` values with generic functions: {{{ $ ghci -XPolyKinds GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help ?> import GHC.Generics ?> import Data.Proxy ?> from (Proxy :: Proxy Int) M1 {unM1 = M1 {unM1 = U1}} ?> from (Proxy :: Proxy Maybe) :5:1: No instance for (Generic (Proxy Maybe)) (maybe you haven't applied enough arguments to a function?) arising from a use of ?from? In the expression: from (Proxy :: Proxy Maybe) In an equation for ?it?: it = from (Proxy :: Proxy Maybe) }}} If `GHC.Generics` enabled `PolyKinds`, that would fix this issue. It would also make many data types in `GHC.Generics` poly-kinded as well, as an added bonus. (I had originally thought `Generic1`/`Rep1` could be poly-kinded, but upon further thought, I think the current GHC generics mechanism assumes that the last type parameter is always of kind `* -> *`.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 16 15:05:05 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Aug 2015 15:05:05 -0000 Subject: [GHC] #10776: DataKinds promotion of String -> Symbol and Natural -> Nat Message-ID: <048.67491201a04ddd5c5f8addf4fce96596@haskell.org> #10776: DataKinds promotion of String -> Symbol and Natural -> Nat -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: DataKinds | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Exactly what it says on the tin. It would be nice if the following would compile: {{{#!hs {-# LANGUAGE DataKinds, KindSignatures, GADTs #-} import GHC.TypeLits import GHC.Natural data X = X String Natural data Y :: X -> * where Y :: Y (X "hello" 4) }}} I kind of assume there's already a ticket for this, but couldn't find one, so figured I'd open one in case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 16 15:43:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Aug 2015 15:43:37 -0000 Subject: [GHC] #10776: DataKinds promotion of String -> Symbol and Natural -> Nat In-Reply-To: <048.67491201a04ddd5c5f8addf4fce96596@haskell.org> References: <048.67491201a04ddd5c5f8addf4fce96596@haskell.org> Message-ID: <063.1a48ec0986b328f4b96674fbfbf57a21@haskell.org> #10776: DataKinds promotion of String -> Symbol and Natural -> Nat -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: DataKinds Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by htebalaka: Old description: > Exactly what it says on the tin. It would be nice if the following would > compile: > > {{{#!hs > {-# LANGUAGE DataKinds, KindSignatures, GADTs #-} > > import GHC.TypeLits > import GHC.Natural > > data X = X String Natural > > data Y :: X -> * where > Y :: Y (X "hello" 4) > }}} > > I kind of assume there's already a ticket for this, but couldn't find > one, so figured I'd open one in case. New description: Exactly what it says on the tin. It would be nice if the following would compile: {{{#!hs {-# LANGUAGE DataKinds, KindSignatures, GADTs #-} import GHC.TypeLits import GHC.Natural data X = X String Natural data Y :: X -> * where Y :: Y ('X "hello" 4) }}} I kind of assume there's already a ticket for this, but couldn't find one, so figured I'd open one in case. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 16 23:48:54 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Aug 2015 23:48:54 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.6ee25ac5a59a56b38b218a9c420cb824@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8226, #8745 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by oerjan): I think what was wrong with my first attempt was forgetting that ''role annotations'' also need the safety check. Also the safety of an explicit role annotation has two sides: * When ''using'' an explicit role annotation, the recursive check for that type is disabled at the use site. I.e. an explicit role annotation is to be interpreted as explicit permission to do the implied coercions `Safe`ly without further ado thereafter. * However, the annotation ''itself'' should not be `Safe` (nor the module containing it) unless the coercions implied by it can be written by hand using what's in scope in the module, plus `coerce` for other types with explicit annotations. This means a recursive check for all its non-`nominal` parameters. Putting this together, the recursive check, when it happens, should cut off whenever an explicit role annotation is reached. A role annotation for a type transfers coercion `Safe`ty responsibility from the module using the role to the module declaring it. So I'll modify point 5, and add a point 6 that became apparent: 5. Explicit role annotations, when used, transfer the responsibility for the `Safe`ty of `coerce`ing a type to the annotating module. 6. To avoid breaking code, none of the new restrictions will apply outside of `Safe` mode. ---- So, to sum up the modified design: * Default inferred role remains `representational`. * Explicit role annotations do indeed have subtly different semantics from implicitly inferred ones: they are considered stated author permission to `coerce` a type, even when not all constructors are in scope at the use site. * Declaring a role annotation, `coerce`ing types, or GND require checking the (non-`nominal`) parameter roles for `Safe`ty. Failure of the check means the module is not `Safe`, but has no other semantic effect. My non-expert attempt to define the recursive `Safe`ty check, probably similar to what GHC used to do: * A nominal role is always `Safe`. * The role of a parameter from an explicit role annotation is `Safe`. * The role of a parameter from a type's implicitly inferred role annotation is `Safe` if: * The type's data constructors are all in scope, and * the roles of all nested type parameters containing the given parameter on the right side of the datatype declaration are `Safe`. ---- A few more thoughts/options: * As I mentioned, there probably should be an extension to make implicitly inferred roles behave as explicit ones for types declared in a module. Maybe `RoleAnnotations` itself will do, or at least imply it. * Since this proposal makes implicit and explicit role annotations subtly different, someone might want to have a way to explicitly declare a role annotation that behaves like an inferred one. Maybe the `inferredRepresentational` idea from my previous message. * By point 6, module encapsulation can still be broken nilly-willy by non-`Safe` modules, even by accident. Perhaps this is a bad idea, and an explicit extension (`NoScopedRolesRestriction`?) should be required to disable the recursive check for non-`Safe` modules. However, this would break backwards compatibility, and probably need a deprecation period. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 17 07:47:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Aug 2015 07:47:38 -0000 Subject: [GHC] #10755: Add `MonadPlus IO` and `Alternative IO` instances In-Reply-To: <042.9475d11a3f91fa4e741f69ce0a266155@haskell.org> References: <042.9475d11a3f91fa4e741f69ce0a266155@haskell.org> Message-ID: <057.8ad972ce68371791dafe2889d42374ee@haskell.org> #10755: Add `MonadPlus IO` and `Alternative IO` instances -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: Resolution: | Keywords: report- | impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1148 -------------------------------------+------------------------------------- Comment (by bgamari): +1 to putting these in `base-orphans`. It's unfortunate that people will need to update their dependency lists, but it seems like the right thing to do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 17 08:13:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Aug 2015 08:13:08 -0000 Subject: [GHC] #10755: Add `MonadPlus IO` and `Alternative IO` instances In-Reply-To: <042.9475d11a3f91fa4e741f69ce0a266155@haskell.org> References: <042.9475d11a3f91fa4e741f69ce0a266155@haskell.org> Message-ID: <057.d3f00b6b0f2dd1dfb6971f8d702563af@haskell.org> #10755: Add `MonadPlus IO` and `Alternative IO` instances -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: Resolution: | Keywords: report- | impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1148 -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:5 bgamari]: > +1 to putting these in `base-orphans`. It's unfortunate that people will need to update their dependency lists, but it seems like the right thing to do. Adding those to `base-orphans` is not the problem (and I'm +1 on that as well). The problem is with already released packages. Specifically, consider the following case: - A package `foo-0.1` relies on `transformer >= 0.4` to supply the `MonadPlus IO` instance. - Now a new `transformers-0.5` is released which lacks the instance. - So now `foo-0.1` breaks when using `base-4.8`+`transformers-0.5`. - `base-4.9` would however have the instance again and `foo-0.1` happens to compile again with `base-4.9`+`transformers-0.5` Now in order to fixup this breakage would need to add upper bounds to the `foo-0.1`, but the problem is we can either - add a `transformers < 0.5` bound to `foo-0.1`, which would block out the sensible `base-4.9`+`transformers-0.5` combination, or - add a `base < 4.9` bound to `foo-0.1`, which block `base-4.9`+`transformers-0.5` as well. What we would need to be able to do is to retrofit the constraint "`base >= 4.9 || transformers < 0.5`", but this requires cabal conditionals and automatic cabal flags, which can't be edited into a package retroactively (for good reason). If this specific constellation affects a very small amount of packages*versions, we can handle it by a combination of cabal-edits and interacting w/ the authors to upload point releases. Otherwise we're faced with some kind of amputation-dilemma (not sure if there's a better term for it: i.e. when we need to amputate healthy install-plan-limbs in order to save the Hackage-patient...). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 17 09:02:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Aug 2015 09:02:48 -0000 Subject: [GHC] #10777: Overlong linker arguments on Windows leads to broken builds with confusing error messages Message-ID: <047.046a9f83230d0273c9346cd501403845@haskell.org> #10777: Overlong linker arguments on Windows leads to broken builds with confusing error messages -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Windows Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I've seen three different issues on Github about this: two in the stack repo for stack users, and one in the yesod repo for a cabal sandbox user: https://github.com/yesodweb/yesod/issues/1020 https://github.com/commercialhaskell/stack/issues/466 https://github.com/commercialhaskell/stack/issues/795 The problem comes down to this: Windows has a limit of 32k on the size of a command string, which can be tripped by GHC's link phase when using a large number of libraries. The ideal situation would be for GHC to have a different way of passing large argument lists to the linker; I don't know how feasible this is, but I wanted to open up a ticket before I started investigating myself in case others have seen this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 17 09:53:36 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Aug 2015 09:53:36 -0000 Subject: [GHC] #10775: Enable PolyKinds in GHC.Generics In-Reply-To: <050.1fb49e8a4f9e9ff5b73b6dbae85f944e@haskell.org> References: <050.1fb49e8a4f9e9ff5b73b6dbae85f944e@haskell.org> Message-ID: <065.023d68edf536999c3f567f5a41e701ed@haskell.org> #10775: Enable PolyKinds in GHC.Generics -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Do you happen to have the output from `-ddump-deriv` available? I'm having a bit of difficulty seeing why this should just work (although I may be missing something obvious). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 17 09:53:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Aug 2015 09:53:55 -0000 Subject: [GHC] #10755: Add `MonadPlus IO` and `Alternative IO` instances In-Reply-To: <042.9475d11a3f91fa4e741f69ce0a266155@haskell.org> References: <042.9475d11a3f91fa4e741f69ce0a266155@haskell.org> Message-ID: <057.2c26d26d12655a7a28da078b12b6f6bb@haskell.org> #10755: Add `MonadPlus IO` and `Alternative IO` instances -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: Resolution: | Keywords: report- | impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1148 -------------------------------------+------------------------------------- Changes (by bergmark): * cc: bergmark (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 17 10:06:32 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Aug 2015 10:06:32 -0000 Subject: [GHC] #9614: ghc --print-(gcc|ld)-linker-flags broken In-Reply-To: <047.8a05a0d53d11d93a9d7fdc38579c7742@haskell.org> References: <047.8a05a0d53d11d93a9d7fdc38579c7742@haskell.org> Message-ID: <062.1f377216872ad5ed643a7b5591a7d214@haskell.org> #9614: ghc --print-(gcc|ld)-linker-flags broken -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 9421 Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Indeed this is a bit unfortunate that this has stood for so long otherwise I would suggest we simply revert the change. As it stands though it seems we have a few compiler releases in the wild with this change so it is more-or-less here to stay. If understand the problem, it seems like the best solution here is to teach Cabal to use `--print-*-flags` ASAP. If this fails, then fall back to looking at `--info`, first with the new field names, and finally the old. It's unfortunate that querying these flags has to be so involved, but that seems to be how things have developed. The other option would be to expose the output as `--info` as a stable interface (which arguably it should be). If we are going to do this we should formally document the fields produced by `--info` so that issues like this don't arise unexpectedly in the future. This could either be as some text in the user guide or a proper type. Thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 17 10:20:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Aug 2015 10:20:37 -0000 Subject: [GHC] #10777: Overlong linker arguments on Windows leads to broken builds with confusing error messages In-Reply-To: <047.046a9f83230d0273c9346cd501403845@haskell.org> References: <047.046a9f83230d0273c9346cd501403845@haskell.org> Message-ID: <062.d91a271716be21a4a1554c7ddb671c0e@haskell.org> #10777: Overlong linker arguments on Windows leads to broken builds with confusing error messages -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by awson): I have a patch for `Cabal` which introduces response files usage for `ar` and `ld`. This speeds things up dramatically in some cases and eliminates some problems with prelinked object files creation when `split-objs` and gcc > 4.8 are used. This technique can clearly be applied to `gcc` invocations also because `gcc` on windows also supports response files (for ages). The problem with this patch is that: 1. I am lazy, and since I use this patch only internally I didn't bother to factor common code out and simply almost copypasted (added a very minor edit) the same code both for `ar` and `ld`. 2. I didn't test anything on the platforms other than `windows` -- perhaps something could be broken there. OTOH, the patch is very simple and could easily be polished to play nicely with a platform specificity. 2. It deals with `Cabal`, not with `ghc`. I didn't read linked content thoroughly, do we need to modify `ghc`, or modifying `Cabal` would suffice? Btw, feature request for adding it to `ghc` [https://ghc.haskell.org/trac/ghc/ticket/8596 exists]. Anyway, if anybody is interested to look at how this works I can attach the patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 17 10:35:51 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Aug 2015 10:35:51 -0000 Subject: [GHC] #10777: Overlong linker arguments on Windows leads to broken builds with confusing error messages In-Reply-To: <047.046a9f83230d0273c9346cd501403845@haskell.org> References: <047.046a9f83230d0273c9346cd501403845@haskell.org> Message-ID: <062.a76dfdd7141548987f24e4d240985491@haskell.org> #10777: Overlong linker arguments on Windows leads to broken builds with confusing error messages -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by snoyberg): I'd very much like to see the Cabal diff, and I'm sure other users would too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 17 10:43:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Aug 2015 10:43:04 -0000 Subject: [GHC] #10777: Overlong linker arguments on Windows leads to broken builds with confusing error messages In-Reply-To: <047.046a9f83230d0273c9346cd501403845@haskell.org> References: <047.046a9f83230d0273c9346cd501403845@haskell.org> Message-ID: <062.40a8805fa334278ea939defc10847c5e@haskell.org> #10777: Overlong linker arguments on Windows leads to broken builds with confusing error messages -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by awson): * Attachment "cabal-rsp.patch" added. Quick and dirty Cabal patch to make it use response files in a couple of ar and ld invocations -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 17 10:43:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Aug 2015 10:43:21 -0000 Subject: [GHC] #10762: On Windows, out-of-codepage characters can cause GHC build to fail In-Reply-To: <047.594293f39928454a6845b64e2efaf718@haskell.org> References: <047.594293f39928454a6845b64e2efaf718@haskell.org> Message-ID: <062.75eec78ffb077e08c363b77642710c1a@haskell.org> #10762: On Windows, out-of-codepage characters can cause GHC build to fail ---------------------------------+----------------------------------------- Reporter: snoyberg | Owner: snoyberg Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6037 | Differential Revisions: ---------------------------------+----------------------------------------- Changes (by snoyberg): * owner: => snoyberg -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 17 10:44:52 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Aug 2015 10:44:52 -0000 Subject: [GHC] #10777: Overlong linker arguments on Windows leads to broken builds with confusing error messages In-Reply-To: <047.046a9f83230d0273c9346cd501403845@haskell.org> References: <047.046a9f83230d0273c9346cd501403845@haskell.org> Message-ID: <062.b577377e4fe1a96df530c3b104657f7d@haskell.org> #10777: Overlong linker arguments on Windows leads to broken builds with confusing error messages -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by awson): More or less relevant is the part behind `withTempFile`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 17 11:10:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Aug 2015 11:10:03 -0000 Subject: [GHC] #10295: Putting SCC in heavily inlined code results in "error: redefinition of global" In-Reply-To: <046.adbcfa466714e863665bb32dacf6e5dc@haskell.org> References: <046.adbcfa466714e863665bb32dacf6e5dc@haskell.org> Message-ID: <061.f81d72929302a44ba94085250c6bcb17@haskell.org> #10295: Putting SCC in heavily inlined code results in "error: redefinition of global" -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 17 11:16:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Aug 2015 11:16:04 -0000 Subject: [GHC] #10759: don't throw BlockedIndefinitelyOn... in main thread In-Reply-To: <044.e96ca394fd0ec7f5ab2bd63075d05667@haskell.org> References: <044.e96ca394fd0ec7f5ab2bd63075d05667@haskell.org> Message-ID: <059.d1b8952eafd4a71a733d0b66c17c20d7@haskell.org> #10759: don't throw BlockedIndefinitelyOn... in main thread -------------------------------------+------------------------------------- Reporter: yokto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * cc: simonmar (added) Comment: Bringing in Simon Marlow on this one. Simon, is there any way to handle this case in RTS? It sounds like this might get a bit yucky. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 17 12:30:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Aug 2015 12:30:24 -0000 Subject: [GHC] #10762: On Windows, out-of-codepage characters can cause GHC build to fail In-Reply-To: <047.594293f39928454a6845b64e2efaf718@haskell.org> References: <047.594293f39928454a6845b64e2efaf718@haskell.org> Message-ID: <062.cae2fb73d7118d18a83fb0aaa1a84ee9@haskell.org> #10762: On Windows, out-of-codepage characters can cause GHC build to fail ---------------------------------+----------------------------------------- Reporter: snoyberg | Owner: snoyberg Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6037 | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by snoyberg): Patch sent to force dump files to be UTF-8 encoded. https://phabricator.haskell.org/D1151 I'm looking into warnings now -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 17 12:51:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Aug 2015 12:51:09 -0000 Subject: [GHC] #6037: Compile-time crash with sources with non-representable unicode characters In-Reply-To: <043.7207ef363a1d98123424aaa571c817fa@haskell.org> References: <043.7207ef363a1d98123424aaa571c817fa@haskell.org> Message-ID: <058.64c607bab83a128d338e5c693a67bc40@haskell.org> #6037: Compile-time crash with sources with non-representable unicode characters -------------------------------------+------------------------------------- Reporter: akio | Owner: snoyberg Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: T6037 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by snoyberg): * owner: => snoyberg -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 17 13:03:43 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Aug 2015 13:03:43 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.fc2df103ed90f71fc99c7c52bd76c2b2@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8226, #8745 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): A few reactions: * I think this proposal holds water, from a technical standpoint. * I'm worried about the efficiency of `Safe`-inference. This proposal requires doing a recursive check, potentially loading new interface files, just for inferring `Safe`ty. This makes me sad. I have no suggestion for improvement, however. * Along similar lines, just expanding a module's import list can change it from un`Safe`-inferred to `Safe`-inferred. Are the extra imported data constructors considered used in the module? That is, do they get "redundant import" warnings? Either answer to that last question seems wrong. * The reason that the default role is representational (phantom, actually) is solely for backward compatibility. In a newly-minted language, I think choosing nominal here would be rather uncontroversial. Is it worth recasting this debate as a move toward a nominal-default? With this change, the `Safe`ty issue goes away. This would be socially harder, but perhaps better in the long run. ------------- Here's a stab at that last point: Plan to introduce, in GHC 7.14, a new extension `PhantomDefaultRoles`. With this extension, roles would work as they do today. Roles would also be `Safe`, because the author declares their knowledge of roles by using this extension. Without the extension enabled, a nominal role is default. We would introduce a warning in GHC 7.12 about this impending change. I don't have a good proposal for how to implement the warning, though -- it would amount to an inefficient recursive check. Maybe someone has a better idea. By making this change via an extension, it's easy for library-writers to upgrade: include a straightforward conditional block in a .cabal file. All packages could be upgrade by something like (I didn't look up concrete syntax) `if impl(ghc >= 7.12) default-extensions: PhantomDefaultRoles`. Easy! ------- In sum, I think that the proposal in comment:42 is feasible, but I'm worried about efficiency. But I think that tackling the larger problem of default roles is better in the long run. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 17 13:23:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Aug 2015 13:23:24 -0000 Subject: [GHC] #10762: On Windows, out-of-codepage characters can cause GHC build to fail In-Reply-To: <047.594293f39928454a6845b64e2efaf718@haskell.org> References: <047.594293f39928454a6845b64e2efaf718@haskell.org> Message-ID: <062.5cf0d5641a36497ee878890befdd3ca4@haskell.org> #10762: On Windows, out-of-codepage characters can cause GHC build to fail ---------------------------------+----------------------------------------- Reporter: snoyberg | Owner: snoyberg Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6037 | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by snoyberg): https://phabricator.haskell.org/D1153 also sent for the warnings, but we can follow up on that in #6037. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 17 13:24:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Aug 2015 13:24:08 -0000 Subject: [GHC] #6037: Compile-time crash with sources with non-representable unicode characters In-Reply-To: <043.7207ef363a1d98123424aaa571c817fa@haskell.org> References: <043.7207ef363a1d98123424aaa571c817fa@haskell.org> Message-ID: <058.9af05d3653a6ab439b9075e236f574bb@haskell.org> #6037: Compile-time crash with sources with non-representable unicode characters -------------------------------------+------------------------------------- Reporter: akio | Owner: snoyberg Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: T6037 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by snoyberg): I've sent https://phabricator.haskell.org/D1153, which turns on transliteration as mentioned above. I'm not intimately familiar with the Handle encoding API, so there may be a better way to do this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 17 14:06:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Aug 2015 14:06:34 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.ee430899bf1fe4c305a2288d92a1dfa3@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8226, #8745 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by oerjan): My hunch about `nominal` default is that it would be annoying in the same way that authors forgetting to provide a useful type class for a type is annoying, but worse because a user of the package ''cannot'' afterwards declare an orphan `Coercible` instance, even if they need it. You could write an explicit coercion function, or use `unsafeCoerce`, but if you were an intermediate package writer declaring a wrapping type, you couldn't then provide `Coercible` for the users of ''your'' type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 17 14:16:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Aug 2015 14:16:27 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.4028eee0892efff2762ba905f62e6334@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8226, #8745 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by oerjan): I was hoping that the cutoff at explicit role annotations would mitigate the efficiency issue - presumably most major packages would have them, or the pragma to make implicit ones explicit. Otherwise, perhaps the interface files could list the needed constructors for an implicit role parameter? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 17 16:42:43 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Aug 2015 16:42:43 -0000 Subject: [GHC] #10775: Enable PolyKinds in GHC.Generics In-Reply-To: <050.1fb49e8a4f9e9ff5b73b6dbae85f944e@haskell.org> References: <050.1fb49e8a4f9e9ff5b73b6dbae85f944e@haskell.org> Message-ID: <065.85cc336ce0d577543ea5359c435b1fdf@haskell.org> #10775: Enable PolyKinds in GHC.Generics -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dreixel): I think what you're after is a very small subset of the changes to GHC.Generics.hs here: https://phabricator.haskell.org/D493?vs=on&id=1690&whitespace=ignore- most#15796e19 Probably just adding the `:: *` kind signatures in the definitions of the representation types, I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 17 17:00:54 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Aug 2015 17:00:54 -0000 Subject: [GHC] #3070: floor(0/0) should not be defined In-Reply-To: <046.e7310ec88130e4aef68644b0cf077a3b@haskell.org> References: <046.e7310ec88130e4aef68644b0cf077a3b@haskell.org> Message-ID: <061.40b3236e35db93e88edf1691cd0ac1ce@haskell.org> #3070: floor(0/0) should not be defined -------------------------------------+------------------------------------- Reporter: carette | Owner: squadette Type: bug | Status: new Priority: lowest | Milestone: 7.12.1 Component: Prelude | Version: 6.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9276 | Blocking: Related Tickets: #10754 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by tristes_tigres): Correctly implemented FP would be actually faster on (most) modern processors, because they implement IEEE754 in hardware. By the way, the whole model of FP computations in Haskell needs to be rethought from scratch. FP operations are influenced by the state of rounding flags and may raise exceptions, but Haskell type system treats them as pure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 17 20:57:54 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Aug 2015 20:57:54 -0000 Subject: [GHC] #8582: Record syntax for pattern synonyms In-Reply-To: <045.711f298e5aa28ce184df85985d614bd2@haskell.org> References: <045.711f298e5aa28ce184df85985d614bd2@haskell.org> Message-ID: <060.952d1b5a4deabd5fdc7dab99aa5e6744@haskell.org> #8582: Record syntax for pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 5144 | Blocking: Related Tickets: | Differential Revisions: Phab:D1152 -------------------------------------+------------------------------------- Changes (by mpickering): * differential: => Phab:D1152 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 17 21:18:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Aug 2015 21:18:03 -0000 Subject: [GHC] #10303: Make it easier to print stack traces when debugging GHC itself In-Reply-To: <047.fb5dc8e7e9aecf901551c4f1b06d6dc4@haskell.org> References: <047.fb5dc8e7e9aecf901551c4f1b06d6dc4@haskell.org> Message-ID: <062.f955e0ddec0b61d4ff3de769c471a13e@haskell.org> #10303: Make it easier to print stack traces when debugging GHC itself -------------------------------------+------------------------------------- Reporter: goldfire | Owner: mpickering Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by mpickering): * owner: goldfire => mpickering -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 17 22:14:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Aug 2015 22:14:57 -0000 Subject: [GHC] #2: rewrite rules, forall, no -fglasgow-exts In-Reply-To: <045.06ea7a403df37fa1d474136f4bf6bb53@haskell.org> References: <045.06ea7a403df37fa1d474136f4bf6bb53@haskell.org> Message-ID: <060.a4e4b70e6539b41daa30628f0693cf9c@haskell.org> #2: rewrite rules, forall, no -fglasgow-exts --------------------------------+---------------------- Reporter: nobody | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: None Resolution: Fixed | Keywords: --------------------------------+---------------------- Comment (by Sergei Trofimovich ): In [changeset:"74897dece3ea92139b552bd711903ce630956df3/ghc" 74897dec/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="74897dece3ea92139b552bd711903ce630956df3" Make rts/ThreadLabels.c threadsafe for debug runtime. rts/ThreadLabels.c has a global hashtable for each running haskell thread. It's not synchronized across OS threads. Was discovered when ran -debug build of ghc itself as: $ ghc-stage2 -j8 +RTS -A256M -l and glibc detected double-free corruption: #2 in __libc_message (do_abort=do_abort at entry=2, fmt=fmt at entry=0x7fe0bcebf368 "*** Error in `%s': %s: 0x%s ***\n") #3 in malloc_printerr (action=3, str=0x7fe0bcebf4c0 "double free or corruption (fasttop)", ptr=) #4 in _int_free (av=, p=, have_lock=0) #5 in stgFree (p=0x7fe060001820) at rts/RtsUtils.c:108 #6 in freeHashTable (table=0x5929320, freeDataFun=0x36374df ) at rts/Hash.c:360 #7 in freeThreadLabelTable () at rts/ThreadLabels.c:37 #8 in hs_exit_ (wait_foreign=rtsFalse) at rts/RtsStartup.c:403 #9 in shutdownHaskellAndExit (n=0, fastExit=0) at rts/RtsStartup.c:481 #10 in hs_main (...) at rts/RtsMain.c:91 #11 in main (...) at ghc/hschooks.c:63 Exposed itself after commit: > commit f6866824ce5cdf5359f0cad78c49d65f6d43af12 > Author: Sergei Trofimovich > Date: Mon Aug 4 08:10:33 2014 -0500 > > ghc --make: add nicer names to RTS threads (threaded IO manager, make workers) Signed-off-by: Sergei Trofimovich Reviewers: austin, simonmar, ezyang, bgamari Reviewed By: ezyang, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1146 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 17 22:14:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Aug 2015 22:14:57 -0000 Subject: [GHC] #3: DiffArray should be instance of Show In-Reply-To: <047.3d7bfcea6c6c5eaaf4a369a972367c38@haskell.org> References: <047.3d7bfcea6c6c5eaaf4a369a972367c38@haskell.org> Message-ID: <062.7a7f3ed7efad0239f138ee85877ec37b@haskell.org> #3: DiffArray should be instance of Show --------------------------+-------------------- Reporter: magunter | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: hslibs/lang | Version: 5.0 Resolution: Fixed | Keywords: --------------------------+-------------------- Comment (by Sergei Trofimovich ): In [changeset:"74897dece3ea92139b552bd711903ce630956df3/ghc" 74897dec/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="74897dece3ea92139b552bd711903ce630956df3" Make rts/ThreadLabels.c threadsafe for debug runtime. rts/ThreadLabels.c has a global hashtable for each running haskell thread. It's not synchronized across OS threads. Was discovered when ran -debug build of ghc itself as: $ ghc-stage2 -j8 +RTS -A256M -l and glibc detected double-free corruption: #2 in __libc_message (do_abort=do_abort at entry=2, fmt=fmt at entry=0x7fe0bcebf368 "*** Error in `%s': %s: 0x%s ***\n") #3 in malloc_printerr (action=3, str=0x7fe0bcebf4c0 "double free or corruption (fasttop)", ptr=) #4 in _int_free (av=, p=, have_lock=0) #5 in stgFree (p=0x7fe060001820) at rts/RtsUtils.c:108 #6 in freeHashTable (table=0x5929320, freeDataFun=0x36374df ) at rts/Hash.c:360 #7 in freeThreadLabelTable () at rts/ThreadLabels.c:37 #8 in hs_exit_ (wait_foreign=rtsFalse) at rts/RtsStartup.c:403 #9 in shutdownHaskellAndExit (n=0, fastExit=0) at rts/RtsStartup.c:481 #10 in hs_main (...) at rts/RtsMain.c:91 #11 in main (...) at ghc/hschooks.c:63 Exposed itself after commit: > commit f6866824ce5cdf5359f0cad78c49d65f6d43af12 > Author: Sergei Trofimovich > Date: Mon Aug 4 08:10:33 2014 -0500 > > ghc --make: add nicer names to RTS threads (threaded IO manager, make workers) Signed-off-by: Sergei Trofimovich Reviewers: austin, simonmar, ezyang, bgamari Reviewed By: ezyang, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1146 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 17 22:14:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Aug 2015 22:14:57 -0000 Subject: [GHC] #4: -fext-core -fno-core behaves funny In-Reply-To: <045.ae3f8b0e845fade77535d5ec02817b6a@haskell.org> References: <045.ae3f8b0e845fade77535d5ec02817b6a@haskell.org> Message-ID: <060.f8dbfd3786c87629f4a6e97bab6a2a15@haskell.org> #4: -fext-core -fno-core behaves funny ---------------------+-------------------- Reporter: josefs | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Driver | Version: None Resolution: Fixed | Keywords: ---------------------+-------------------- Comment (by Sergei Trofimovich ): In [changeset:"74897dece3ea92139b552bd711903ce630956df3/ghc" 74897dec/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="74897dece3ea92139b552bd711903ce630956df3" Make rts/ThreadLabels.c threadsafe for debug runtime. rts/ThreadLabels.c has a global hashtable for each running haskell thread. It's not synchronized across OS threads. Was discovered when ran -debug build of ghc itself as: $ ghc-stage2 -j8 +RTS -A256M -l and glibc detected double-free corruption: #2 in __libc_message (do_abort=do_abort at entry=2, fmt=fmt at entry=0x7fe0bcebf368 "*** Error in `%s': %s: 0x%s ***\n") #3 in malloc_printerr (action=3, str=0x7fe0bcebf4c0 "double free or corruption (fasttop)", ptr=) #4 in _int_free (av=, p=, have_lock=0) #5 in stgFree (p=0x7fe060001820) at rts/RtsUtils.c:108 #6 in freeHashTable (table=0x5929320, freeDataFun=0x36374df ) at rts/Hash.c:360 #7 in freeThreadLabelTable () at rts/ThreadLabels.c:37 #8 in hs_exit_ (wait_foreign=rtsFalse) at rts/RtsStartup.c:403 #9 in shutdownHaskellAndExit (n=0, fastExit=0) at rts/RtsStartup.c:481 #10 in hs_main (...) at rts/RtsMain.c:91 #11 in main (...) at ghc/hschooks.c:63 Exposed itself after commit: > commit f6866824ce5cdf5359f0cad78c49d65f6d43af12 > Author: Sergei Trofimovich > Date: Mon Aug 4 08:10:33 2014 -0500 > > ghc --make: add nicer names to RTS threads (threaded IO manager, make workers) Signed-off-by: Sergei Trofimovich Reviewers: austin, simonmar, ezyang, bgamari Reviewed By: ezyang, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1146 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 17 22:14:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Aug 2015 22:14:57 -0000 Subject: [GHC] #5: fails if library has main() In-Reply-To: <045.5aafe47c7b47732eda828244576abf66@haskell.org> References: <045.5aafe47c7b47732eda828244576abf66@haskell.org> Message-ID: <060.2fb44835657e5816a09dad2f1fa525ea@haskell.org> #5: fails if library has main() -----------------------+---------------------- Reporter: cwitty | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Driver | Version: 5.02 Resolution: Wont Fix | Keywords: -----------------------+---------------------- Comment (by Sergei Trofimovich ): In [changeset:"74897dece3ea92139b552bd711903ce630956df3/ghc" 74897dec/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="74897dece3ea92139b552bd711903ce630956df3" Make rts/ThreadLabels.c threadsafe for debug runtime. rts/ThreadLabels.c has a global hashtable for each running haskell thread. It's not synchronized across OS threads. Was discovered when ran -debug build of ghc itself as: $ ghc-stage2 -j8 +RTS -A256M -l and glibc detected double-free corruption: #2 in __libc_message (do_abort=do_abort at entry=2, fmt=fmt at entry=0x7fe0bcebf368 "*** Error in `%s': %s: 0x%s ***\n") #3 in malloc_printerr (action=3, str=0x7fe0bcebf4c0 "double free or corruption (fasttop)", ptr=) #4 in _int_free (av=, p=, have_lock=0) #5 in stgFree (p=0x7fe060001820) at rts/RtsUtils.c:108 #6 in freeHashTable (table=0x5929320, freeDataFun=0x36374df ) at rts/Hash.c:360 #7 in freeThreadLabelTable () at rts/ThreadLabels.c:37 #8 in hs_exit_ (wait_foreign=rtsFalse) at rts/RtsStartup.c:403 #9 in shutdownHaskellAndExit (n=0, fastExit=0) at rts/RtsStartup.c:481 #10 in hs_main (...) at rts/RtsMain.c:91 #11 in main (...) at ghc/hschooks.c:63 Exposed itself after commit: > commit f6866824ce5cdf5359f0cad78c49d65f6d43af12 > Author: Sergei Trofimovich > Date: Mon Aug 4 08:10:33 2014 -0500 > > ghc --make: add nicer names to RTS threads (threaded IO manager, make workers) Signed-off-by: Sergei Trofimovich Reviewers: austin, simonmar, ezyang, bgamari Reviewed By: ezyang, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1146 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 17 22:14:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Aug 2015 22:14:57 -0000 Subject: [GHC] #8: Regex failure In-Reply-To: <045.f8ed3d6828e64883829f70bbb0708aa0@haskell.org> References: <045.f8ed3d6828e64883829f70bbb0708aa0@haskell.org> Message-ID: <060.2955f5923a8e37a08135407270ee9fec@haskell.org> #8: Regex failure --------------------------+---------------------- Reporter: xoltar | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: hslibs/text | Version: 5.02 Resolution: Fixed | Keywords: --------------------------+---------------------- Comment (by Sergei Trofimovich ): In [changeset:"74897dece3ea92139b552bd711903ce630956df3/ghc" 74897dec/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="74897dece3ea92139b552bd711903ce630956df3" Make rts/ThreadLabels.c threadsafe for debug runtime. rts/ThreadLabels.c has a global hashtable for each running haskell thread. It's not synchronized across OS threads. Was discovered when ran -debug build of ghc itself as: $ ghc-stage2 -j8 +RTS -A256M -l and glibc detected double-free corruption: #2 in __libc_message (do_abort=do_abort at entry=2, fmt=fmt at entry=0x7fe0bcebf368 "*** Error in `%s': %s: 0x%s ***\n") #3 in malloc_printerr (action=3, str=0x7fe0bcebf4c0 "double free or corruption (fasttop)", ptr=) #4 in _int_free (av=, p=, have_lock=0) #5 in stgFree (p=0x7fe060001820) at rts/RtsUtils.c:108 #6 in freeHashTable (table=0x5929320, freeDataFun=0x36374df ) at rts/Hash.c:360 #7 in freeThreadLabelTable () at rts/ThreadLabels.c:37 #8 in hs_exit_ (wait_foreign=rtsFalse) at rts/RtsStartup.c:403 #9 in shutdownHaskellAndExit (n=0, fastExit=0) at rts/RtsStartup.c:481 #10 in hs_main (...) at rts/RtsMain.c:91 #11 in main (...) at ghc/hschooks.c:63 Exposed itself after commit: > commit f6866824ce5cdf5359f0cad78c49d65f6d43af12 > Author: Sergei Trofimovich > Date: Mon Aug 4 08:10:33 2014 -0500 > > ghc --make: add nicer names to RTS threads (threaded IO manager, make workers) Signed-off-by: Sergei Trofimovich Reviewers: austin, simonmar, ezyang, bgamari Reviewed By: ezyang, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1146 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 17 22:14:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Aug 2015 22:14:57 -0000 Subject: [GHC] #6: Debugging info confuses runtime linker In-Reply-To: <047.f0ad9cac1869b4c4c3b4613e6dbb6f53@haskell.org> References: <047.f0ad9cac1869b4c4c3b4613e6dbb6f53@haskell.org> Message-ID: <062.06a73200ddc87e26d20252e42a0f2b7d@haskell.org> #6: Debugging info confuses runtime linker -----------------------------+--------------------- Reporter: simonmar | Owner: sewardj Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 5.02 Resolution: Fixed | Keywords: -----------------------------+--------------------- Comment (by Sergei Trofimovich ): In [changeset:"74897dece3ea92139b552bd711903ce630956df3/ghc" 74897dec/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="74897dece3ea92139b552bd711903ce630956df3" Make rts/ThreadLabels.c threadsafe for debug runtime. rts/ThreadLabels.c has a global hashtable for each running haskell thread. It's not synchronized across OS threads. Was discovered when ran -debug build of ghc itself as: $ ghc-stage2 -j8 +RTS -A256M -l and glibc detected double-free corruption: #2 in __libc_message (do_abort=do_abort at entry=2, fmt=fmt at entry=0x7fe0bcebf368 "*** Error in `%s': %s: 0x%s ***\n") #3 in malloc_printerr (action=3, str=0x7fe0bcebf4c0 "double free or corruption (fasttop)", ptr=) #4 in _int_free (av=, p=, have_lock=0) #5 in stgFree (p=0x7fe060001820) at rts/RtsUtils.c:108 #6 in freeHashTable (table=0x5929320, freeDataFun=0x36374df ) at rts/Hash.c:360 #7 in freeThreadLabelTable () at rts/ThreadLabels.c:37 #8 in hs_exit_ (wait_foreign=rtsFalse) at rts/RtsStartup.c:403 #9 in shutdownHaskellAndExit (n=0, fastExit=0) at rts/RtsStartup.c:481 #10 in hs_main (...) at rts/RtsMain.c:91 #11 in main (...) at ghc/hschooks.c:63 Exposed itself after commit: > commit f6866824ce5cdf5359f0cad78c49d65f6d43af12 > Author: Sergei Trofimovich > Date: Mon Aug 4 08:10:33 2014 -0500 > > ghc --make: add nicer names to RTS threads (threaded IO manager, make workers) Signed-off-by: Sergei Trofimovich Reviewers: austin, simonmar, ezyang, bgamari Reviewed By: ezyang, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1146 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 17 22:14:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Aug 2015 22:14:57 -0000 Subject: [GHC] #7: dodgy case of unboxed tuple type In-Reply-To: <046.d0162c2c79173b600f159e4160473f60@haskell.org> References: <046.d0162c2c79173b600f159e4160473f60@haskell.org> Message-ID: <061.a72fa1189f85b1b614cc408654fd4a56@haskell.org> #7: dodgy case of unboxed tuple type -----------------------+-------------------- Reporter: mtehver | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 5.02 Resolution: Fixed | Keywords: -----------------------+-------------------- Comment (by Sergei Trofimovich ): In [changeset:"74897dece3ea92139b552bd711903ce630956df3/ghc" 74897dec/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="74897dece3ea92139b552bd711903ce630956df3" Make rts/ThreadLabels.c threadsafe for debug runtime. rts/ThreadLabels.c has a global hashtable for each running haskell thread. It's not synchronized across OS threads. Was discovered when ran -debug build of ghc itself as: $ ghc-stage2 -j8 +RTS -A256M -l and glibc detected double-free corruption: #2 in __libc_message (do_abort=do_abort at entry=2, fmt=fmt at entry=0x7fe0bcebf368 "*** Error in `%s': %s: 0x%s ***\n") #3 in malloc_printerr (action=3, str=0x7fe0bcebf4c0 "double free or corruption (fasttop)", ptr=) #4 in _int_free (av=, p=, have_lock=0) #5 in stgFree (p=0x7fe060001820) at rts/RtsUtils.c:108 #6 in freeHashTable (table=0x5929320, freeDataFun=0x36374df ) at rts/Hash.c:360 #7 in freeThreadLabelTable () at rts/ThreadLabels.c:37 #8 in hs_exit_ (wait_foreign=rtsFalse) at rts/RtsStartup.c:403 #9 in shutdownHaskellAndExit (n=0, fastExit=0) at rts/RtsStartup.c:481 #10 in hs_main (...) at rts/RtsMain.c:91 #11 in main (...) at ghc/hschooks.c:63 Exposed itself after commit: > commit f6866824ce5cdf5359f0cad78c49d65f6d43af12 > Author: Sergei Trofimovich > Date: Mon Aug 4 08:10:33 2014 -0500 > > ghc --make: add nicer names to RTS threads (threaded IO manager, make workers) Signed-off-by: Sergei Trofimovich Reviewers: austin, simonmar, ezyang, bgamari Reviewed By: ezyang, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1146 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 17 22:14:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Aug 2015 22:14:57 -0000 Subject: [GHC] #9: GHCI for Win32 crashes with many options In-Reply-To: <046.dc944f46afdf1d8f330553aef7d98981@haskell.org> References: <046.dc944f46afdf1d8f330553aef7d98981@haskell.org> Message-ID: <061.dca476e6ca3a057befda32da604e062e@haskell.org> #9: GHCI for Win32 crashes with many options ----------------------+-------------------- Reporter: fizzgig | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: None | Version: 5.02 Resolution: Fixed | Keywords: ----------------------+-------------------- Comment (by Sergei Trofimovich ): In [changeset:"74897dece3ea92139b552bd711903ce630956df3/ghc" 74897dec/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="74897dece3ea92139b552bd711903ce630956df3" Make rts/ThreadLabels.c threadsafe for debug runtime. rts/ThreadLabels.c has a global hashtable for each running haskell thread. It's not synchronized across OS threads. Was discovered when ran -debug build of ghc itself as: $ ghc-stage2 -j8 +RTS -A256M -l and glibc detected double-free corruption: #2 in __libc_message (do_abort=do_abort at entry=2, fmt=fmt at entry=0x7fe0bcebf368 "*** Error in `%s': %s: 0x%s ***\n") #3 in malloc_printerr (action=3, str=0x7fe0bcebf4c0 "double free or corruption (fasttop)", ptr=) #4 in _int_free (av=, p=, have_lock=0) #5 in stgFree (p=0x7fe060001820) at rts/RtsUtils.c:108 #6 in freeHashTable (table=0x5929320, freeDataFun=0x36374df ) at rts/Hash.c:360 #7 in freeThreadLabelTable () at rts/ThreadLabels.c:37 #8 in hs_exit_ (wait_foreign=rtsFalse) at rts/RtsStartup.c:403 #9 in shutdownHaskellAndExit (n=0, fastExit=0) at rts/RtsStartup.c:481 #10 in hs_main (...) at rts/RtsMain.c:91 #11 in main (...) at ghc/hschooks.c:63 Exposed itself after commit: > commit f6866824ce5cdf5359f0cad78c49d65f6d43af12 > Author: Sergei Trofimovich > Date: Mon Aug 4 08:10:33 2014 -0500 > > ghc --make: add nicer names to RTS threads (threaded IO manager, make workers) Signed-off-by: Sergei Trofimovich Reviewers: austin, simonmar, ezyang, bgamari Reviewed By: ezyang, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1146 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 17 22:14:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Aug 2015 22:14:58 -0000 Subject: [GHC] #10: undefined reference to `Main_main_closur In-Reply-To: <045.59d858883487eb68b7c9d05072b43b58@haskell.org> References: <045.59d858883487eb68b7c9d05072b43b58@haskell.org> Message-ID: <060.0cc0faeb4bd8ca1df7d910f3101a3ae7@haskell.org> #10: undefined reference to `Main_main_closur -----------------------+-------------------- Reporter: nobody | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 5.02 Resolution: Invalid | Keywords: -----------------------+-------------------- Comment (by Sergei Trofimovich ): In [changeset:"74897dece3ea92139b552bd711903ce630956df3/ghc" 74897dec/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="74897dece3ea92139b552bd711903ce630956df3" Make rts/ThreadLabels.c threadsafe for debug runtime. rts/ThreadLabels.c has a global hashtable for each running haskell thread. It's not synchronized across OS threads. Was discovered when ran -debug build of ghc itself as: $ ghc-stage2 -j8 +RTS -A256M -l and glibc detected double-free corruption: #2 in __libc_message (do_abort=do_abort at entry=2, fmt=fmt at entry=0x7fe0bcebf368 "*** Error in `%s': %s: 0x%s ***\n") #3 in malloc_printerr (action=3, str=0x7fe0bcebf4c0 "double free or corruption (fasttop)", ptr=) #4 in _int_free (av=, p=, have_lock=0) #5 in stgFree (p=0x7fe060001820) at rts/RtsUtils.c:108 #6 in freeHashTable (table=0x5929320, freeDataFun=0x36374df ) at rts/Hash.c:360 #7 in freeThreadLabelTable () at rts/ThreadLabels.c:37 #8 in hs_exit_ (wait_foreign=rtsFalse) at rts/RtsStartup.c:403 #9 in shutdownHaskellAndExit (n=0, fastExit=0) at rts/RtsStartup.c:481 #10 in hs_main (...) at rts/RtsMain.c:91 #11 in main (...) at ghc/hschooks.c:63 Exposed itself after commit: > commit f6866824ce5cdf5359f0cad78c49d65f6d43af12 > Author: Sergei Trofimovich > Date: Mon Aug 4 08:10:33 2014 -0500 > > ghc --make: add nicer names to RTS threads (threaded IO manager, make workers) Signed-off-by: Sergei Trofimovich Reviewers: austin, simonmar, ezyang, bgamari Reviewed By: ezyang, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1146 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 17 22:14:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Aug 2015 22:14:58 -0000 Subject: [GHC] #11: No error from --make -o out when no main In-Reply-To: <042.0dc32cc82542de83e63c07b7c50ba1dd@haskell.org> References: <042.0dc32cc82542de83e63c07b7c50ba1dd@haskell.org> Message-ID: <057.ca5f656d511b197cb8e2d88b08377731@haskell.org> #11: No error from --make -o out when no main ---------------------+---------------------- Reporter: rrt | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: None | Version: None Resolution: Fixed | Keywords: ---------------------+---------------------- Comment (by Sergei Trofimovich ): In [changeset:"74897dece3ea92139b552bd711903ce630956df3/ghc" 74897dec/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="74897dece3ea92139b552bd711903ce630956df3" Make rts/ThreadLabels.c threadsafe for debug runtime. rts/ThreadLabels.c has a global hashtable for each running haskell thread. It's not synchronized across OS threads. Was discovered when ran -debug build of ghc itself as: $ ghc-stage2 -j8 +RTS -A256M -l and glibc detected double-free corruption: #2 in __libc_message (do_abort=do_abort at entry=2, fmt=fmt at entry=0x7fe0bcebf368 "*** Error in `%s': %s: 0x%s ***\n") #3 in malloc_printerr (action=3, str=0x7fe0bcebf4c0 "double free or corruption (fasttop)", ptr=) #4 in _int_free (av=, p=, have_lock=0) #5 in stgFree (p=0x7fe060001820) at rts/RtsUtils.c:108 #6 in freeHashTable (table=0x5929320, freeDataFun=0x36374df ) at rts/Hash.c:360 #7 in freeThreadLabelTable () at rts/ThreadLabels.c:37 #8 in hs_exit_ (wait_foreign=rtsFalse) at rts/RtsStartup.c:403 #9 in shutdownHaskellAndExit (n=0, fastExit=0) at rts/RtsStartup.c:481 #10 in hs_main (...) at rts/RtsMain.c:91 #11 in main (...) at ghc/hschooks.c:63 Exposed itself after commit: > commit f6866824ce5cdf5359f0cad78c49d65f6d43af12 > Author: Sergei Trofimovich > Date: Mon Aug 4 08:10:33 2014 -0500 > > ghc --make: add nicer names to RTS threads (threaded IO manager, make workers) Signed-off-by: Sergei Trofimovich Reviewers: austin, simonmar, ezyang, bgamari Reviewed By: ezyang, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1146 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 17 23:09:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Aug 2015 23:09:20 -0000 Subject: [GHC] #10775: Enable PolyKinds in GHC.Generics In-Reply-To: <050.1fb49e8a4f9e9ff5b73b6dbae85f944e@haskell.org> References: <050.1fb49e8a4f9e9ff5b73b6dbae85f944e@haskell.org> Message-ID: <065.6be933e5bda4faaa9802017a70bbd847@haskell.org> #10775: Enable PolyKinds in GHC.Generics -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by RyanGlScott): bgamari: The output of `-ddump-deriv` is extremely long, but here are the parts pertaining to `Proxy`: {{{ ==================== Derived instances ==================== Derived instances: instance forall (k_a21F :: BOX) (t_a21G :: k_a21F). GHC.Generics.Generic (Data.Proxy.Proxy t_a21G) where GHC.Generics.from Data.Proxy.Proxy = GHC.Generics.M1 (GHC.Generics.M1 GHC.Generics.U1) GHC.Generics.to (GHC.Generics.M1 (GHC.Generics.M1 GHC.Generics.U1)) = Data.Proxy.Proxy instance GHC.Generics.Datatype where GHC.Generics.datatypeName _ = "Proxy" GHC.Generics.moduleName _ = "Data.Proxy" GHC.Generics.packageName _ = "base" instance GHC.Generics.Constructor where GHC.Generics.conName _ = "Proxy" Generic representation: Generated datatypes for meta-information: GHC.Generics.D1Proxy GHC.Generics.C1_0Proxy Representation types: type GHC.Generics.Rep (Data.Proxy.Proxy t_a21E) = GHC.Generics.D1 }}} That definitely doesn't look right, especially since it should be that `Rep (Proxy t) = D1 D1Proxy (C1 C1_0Proxy U1)`. Luckily, this may be a moot issue. I wasn't aware of Phab:D493, which happens to enable `PolyKinds` in `GHC.Generics` as a happy coincidence. Therefore, this is probably a duplicate of #9766. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 18 10:35:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Aug 2015 10:35:50 -0000 Subject: [GHC] #10778: GHC doesn't infer all constrains Message-ID: <046.c3c6007a301d4e9f2bfd6528e390abd4@haskell.org> #10778: GHC doesn't infer all constrains -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Hello! Let's consider following signatures: {{{ class (IndexOf a cont ~ idx, ElementByIdx idx cont ~ a, Measurable cont) => Container cont idx a class Container cont idx a => Appendable cont idx a class HasContainer a cont | a -> cont class Monad m => RefBuilder3 a m ref | a m -> ref where mkRef3 :: a -> m (ref a) }}} Now when I define following instance: {{{ instance (PtrFrom idx i, Appendable cont idx a, HasContainer g cont, Monad m) => RefBuilder3 a (GraphBuilderT g m) (Ptr i) where mkRef3 = undefined }}} I get an error: {{{ Illegal instance declaration for ?RefBuilder3 a (GraphBuilderT g m) (Ptr i)? The liberal coverage condition fails in class ?RefBuilder3? for functional dependency: ?a m -> ref? Reason: lhs types ?a?, ?GraphBuilderT g m? do not jointly determine rhs type ?Ptr i? In the instance declaration for ?RefBuilder3 a (GraphBuilderT g m) (Ptr i)? }}} But when I add the constraint to the instance head: {{{ instance (PtrFrom idx i, Appendable cont idx a, HasContainer g cont, Monad m, IndexOf a cont ~ idx) => RefBuilder3 a (GraphBuilderT g m) (Ptr i) where mkRef3 a = fmap ptrFrom . withGraph . append $ a }}} It compiles fine. What's interesting, the constraint should be inferred by GHC, because we've got following funds here: {{{ g -> cont -- from HasContainer cont a -> idx -- from Appendable -> Container }}} Is this a GHC bug or am I missing something? If thats a bug, I will try to clean the code and make a minimal example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 18 10:37:53 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Aug 2015 10:37:53 -0000 Subject: [GHC] #10778: GHC doesn't infer all constrains In-Reply-To: <046.c3c6007a301d4e9f2bfd6528e390abd4@haskell.org> References: <046.c3c6007a301d4e9f2bfd6528e390abd4@haskell.org> Message-ID: <061.2f02fd1dd85881212f06abda69d4931e@haskell.org> #10778: GHC doesn't infer all constrains -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by danilo2: Old description: > Hello! Let's consider following signatures: > {{{ > class (IndexOf a cont ~ idx, ElementByIdx idx cont ~ a, Measurable cont) > => Container cont idx a > class Container cont idx a => Appendable cont idx a > class HasContainer a cont | a -> cont > class Monad m => RefBuilder3 a m ref | a m -> ref where > mkRef3 :: a -> m (ref a) > > }}} > > Now when I define following instance: > > {{{ > instance (PtrFrom idx i, Appendable cont idx a, HasContainer g cont, > Monad m) > => RefBuilder3 a (GraphBuilderT g m) (Ptr i) where > mkRef3 = undefined > }}} > > I get an error: > > {{{ > Illegal instance declaration for > ?RefBuilder3 a (GraphBuilderT g m) (Ptr i)? > The liberal coverage condition fails in class ?RefBuilder3? > for functional dependency: ?a m -> ref? > Reason: lhs types ?a?, ?GraphBuilderT g m? > do not jointly determine rhs type ?Ptr i? > In the instance declaration for > ?RefBuilder3 a (GraphBuilderT g m) (Ptr i)? > }}} > > But when I add the constraint to the instance head: > > {{{ > instance (PtrFrom idx i, Appendable cont idx a, HasContainer g cont, > Monad m, IndexOf a cont ~ idx) > => RefBuilder3 a (GraphBuilderT g m) (Ptr i) where > mkRef3 a = fmap ptrFrom . withGraph . append $ a > }}} > > It compiles fine. What's interesting, the constraint should be inferred > by GHC, because we've got following funds here: > {{{ > g -> cont -- from HasContainer > cont a -> idx -- from Appendable -> Container > }}} > > Is this a GHC bug or am I missing something? If thats a bug, I will try > to clean the code and make a minimal example. New description: Hello! Let's consider following signatures: {{{ class (IndexOf a cont ~ idx, ElementByIdx idx cont ~ a, Measurable cont) => Container cont idx a class Container cont idx a => Appendable cont idx a class HasContainer a cont | a -> cont class PtrFrom p i | p -> i class Monad m => RefBuilder3 a m ref | a m -> ref where mkRef3 :: a -> m (ref a) }}} Now when I define following instance: {{{ instance (PtrFrom idx i, Appendable cont idx a, HasContainer g cont, Monad m) => RefBuilder3 a (GraphBuilderT g m) (Ptr i) where mkRef3 = undefined }}} I get an error: {{{ Illegal instance declaration for ?RefBuilder3 a (GraphBuilderT g m) (Ptr i)? The liberal coverage condition fails in class ?RefBuilder3? for functional dependency: ?a m -> ref? Reason: lhs types ?a?, ?GraphBuilderT g m? do not jointly determine rhs type ?Ptr i? In the instance declaration for ?RefBuilder3 a (GraphBuilderT g m) (Ptr i)? }}} But when I add the constraint to the instance head: {{{ instance (PtrFrom idx i, Appendable cont idx a, HasContainer g cont, Monad m, IndexOf a cont ~ idx) => RefBuilder3 a (GraphBuilderT g m) (Ptr i) where mkRef3 a = fmap ptrFrom . withGraph . append $ a }}} It compiles fine. What's interesting, the constraint should be inferred by GHC, because we've got following funds here: {{{ g -> cont -- from HasContainer cont a -> idx -- from Appendable -> Container idx -> i -- from PtrFrom }}} Is this a GHC bug or am I missing something? If thats a bug, I will try to clean the code and make a minimal example. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 18 10:38:20 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Aug 2015 10:38:20 -0000 Subject: [GHC] #10778: GHC doesn't infer all constrains In-Reply-To: <046.c3c6007a301d4e9f2bfd6528e390abd4@haskell.org> References: <046.c3c6007a301d4e9f2bfd6528e390abd4@haskell.org> Message-ID: <061.1201e614848474054574c0b3cc5f1415@haskell.org> #10778: GHC doesn't infer all constrains -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by danilo2: Old description: > Hello! Let's consider following signatures: > {{{ > class (IndexOf a cont ~ idx, ElementByIdx idx cont ~ a, Measurable cont) > => Container cont idx a > class Container cont idx a => Appendable cont idx a > class HasContainer a cont | a -> cont > class PtrFrom p i | p -> i > class Monad m => RefBuilder3 a m ref | a m -> ref where > mkRef3 :: a -> m (ref a) > > }}} > > Now when I define following instance: > > {{{ > instance (PtrFrom idx i, Appendable cont idx a, HasContainer g cont, > Monad m) > => RefBuilder3 a (GraphBuilderT g m) (Ptr i) where > mkRef3 = undefined > }}} > > I get an error: > > {{{ > Illegal instance declaration for > ?RefBuilder3 a (GraphBuilderT g m) (Ptr i)? > The liberal coverage condition fails in class ?RefBuilder3? > for functional dependency: ?a m -> ref? > Reason: lhs types ?a?, ?GraphBuilderT g m? > do not jointly determine rhs type ?Ptr i? > In the instance declaration for > ?RefBuilder3 a (GraphBuilderT g m) (Ptr i)? > }}} > > But when I add the constraint to the instance head: > > {{{ > instance (PtrFrom idx i, Appendable cont idx a, HasContainer g cont, > Monad m, IndexOf a cont ~ idx) > => RefBuilder3 a (GraphBuilderT g m) (Ptr i) where > mkRef3 a = fmap ptrFrom . withGraph . append $ a > }}} > > It compiles fine. What's interesting, the constraint should be inferred > by GHC, because we've got following funds here: > {{{ > g -> cont -- from HasContainer > cont a -> idx -- from Appendable -> Container > idx -> i -- from PtrFrom > }}} > > Is this a GHC bug or am I missing something? If thats a bug, I will try > to clean the code and make a minimal example. New description: Hello! Let's consider following signatures: {{{ class (IndexOf a cont ~ idx, ElementByIdx idx cont ~ a, Measurable cont) => Container cont idx a class Container cont idx a => Appendable cont idx a class HasContainer a cont | a -> cont class PtrFrom p i | p -> i class Monad m => RefBuilder3 a m ref | a m -> ref where mkRef3 :: a -> m (ref a) }}} Now when I define following instance: {{{ instance (PtrFrom idx i, Appendable cont idx a, HasContainer g cont, Monad m) => RefBuilder3 a (GraphBuilderT g m) (Ptr i) where mkRef3 = undefined }}} I get an error: {{{ Illegal instance declaration for ?RefBuilder3 a (GraphBuilderT g m) (Ptr i)? The liberal coverage condition fails in class ?RefBuilder3? for functional dependency: ?a m -> ref? Reason: lhs types ?a?, ?GraphBuilderT g m? do not jointly determine rhs type ?Ptr i? In the instance declaration for ?RefBuilder3 a (GraphBuilderT g m) (Ptr i)? }}} But when I add the constraint to the instance head: {{{ instance (PtrFrom idx i, Appendable cont idx a, HasContainer g cont, Monad m, IndexOf a cont ~ idx) => RefBuilder3 a (GraphBuilderT g m) (Ptr i) where mkRef3 a = fmap ptrFrom . withGraph . append $ a }}} It compiles fine. What's interesting, the constraint should be inferred by GHC, because we've got following fundeps here: {{{ g -> cont -- from HasContainer cont a -> idx -- from Appendable -> Container idx -> i -- from PtrFrom }}} Is this a GHC bug or am I missing something? If thats a bug, I will try to clean the code and make a minimal example. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 18 16:33:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Aug 2015 16:33:06 -0000 Subject: [GHC] #10762: On Windows, out-of-codepage characters can cause GHC build to fail In-Reply-To: <047.594293f39928454a6845b64e2efaf718@haskell.org> References: <047.594293f39928454a6845b64e2efaf718@haskell.org> Message-ID: <062.1bd9819471c501cb5404b67a3b47b711@haskell.org> #10762: On Windows, out-of-codepage characters can cause GHC build to fail ---------------------------------+----------------------------------------- Reporter: snoyberg | Owner: snoyberg Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6037 | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by Ben Gamari ): In [changeset:"ab9403d5e6eb4f0a2e917d7edcd5821262432b26/ghc" ab9403d5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ab9403d5e6eb4f0a2e917d7edcd5821262432b26" Dump files always use UTF8 encoding #10762 When the Windows codepage or *nix LANG variable is something besides UTF-8, dumping to file can cause GHC to exit currently. This changes the output encoding for files to match the defined input encoding for Haskell source code (UTF-8), making it easier for users and build tools to capture this output. Test Plan: Create a Haskell source file with non-Latin characters for identifier names and compile with: LANG=C ghc -ddump-to-file -ddump-hi filename.hs -fforce-recomp Without this patch, it will fail. With this patch, it succeeds Reviewers: austin, rwbarton, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1151 GHC Trac Issues: #10762 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 18 16:33:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Aug 2015 16:33:06 -0000 Subject: [GHC] #10762: On Windows, out-of-codepage characters can cause GHC build to fail In-Reply-To: <047.594293f39928454a6845b64e2efaf718@haskell.org> References: <047.594293f39928454a6845b64e2efaf718@haskell.org> Message-ID: <062.cf3311b14f0cf55d186b548297857d37@haskell.org> #10762: On Windows, out-of-codepage characters can cause GHC build to fail ---------------------------------+----------------------------------------- Reporter: snoyberg | Owner: snoyberg Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6037 | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by Ben Gamari ): In [changeset:"22aca5368864070bbed3b44dca3ce57e243bf415/ghc" 22aca536/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="22aca5368864070bbed3b44dca3ce57e243bf415" Transliterate unknown characters at output This avoids the compiler from crashing when, for example, a warning contains a non-Latin identifier and the LANG variable is set to C. Fixes #6037. Test Plan: Create a Haskell source file containing an identifier with non-Latin characters and no type signature. Compile with `LANG=C ghc -Wall foo.hs`, and it should fail. With this patch, it will succeed. Reviewers: austin, rwbarton, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1153 GHC Trac Issues: #6037, #10762 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 18 16:33:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Aug 2015 16:33:06 -0000 Subject: [GHC] #6037: Compile-time crash with sources with non-representable unicode characters In-Reply-To: <043.7207ef363a1d98123424aaa571c817fa@haskell.org> References: <043.7207ef363a1d98123424aaa571c817fa@haskell.org> Message-ID: <058.72697a149e05e95e077a4d47820db0e5@haskell.org> #6037: Compile-time crash with sources with non-representable unicode characters -------------------------------------+------------------------------------- Reporter: akio | Owner: snoyberg Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: T6037 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"22aca5368864070bbed3b44dca3ce57e243bf415/ghc" 22aca536/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="22aca5368864070bbed3b44dca3ce57e243bf415" Transliterate unknown characters at output This avoids the compiler from crashing when, for example, a warning contains a non-Latin identifier and the LANG variable is set to C. Fixes #6037. Test Plan: Create a Haskell source file containing an identifier with non-Latin characters and no type signature. Compile with `LANG=C ghc -Wall foo.hs`, and it should fail. With this patch, it will succeed. Reviewers: austin, rwbarton, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1153 GHC Trac Issues: #6037, #10762 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 18 16:33:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Aug 2015 16:33:06 -0000 Subject: [GHC] #9381: Implement -rdynamic In-Reply-To: <056.1019797b6ed554879c40e702f4d5c1f2@haskell.org> References: <056.1019797b6ed554879c40e702f4d5c1f2@haskell.org> Message-ID: <071.f739421d9adada6c33b6b3b576eab628@haskell.org> #9381: Implement -rdynamic -------------------------------------+------------------------------------- Reporter: | Owner: Phyx- facundo.dominguez | Type: feature request | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7015 | Differential Revisions: Phab:D1149 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b17ec5674f26b0b65dda4ec446e0b9b5336b7562/ghc" b17ec567/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b17ec5674f26b0b65dda4ec446e0b9b5336b7562" Fix rdynamic flag and test on Windows The rdynamic tests and feature are marked broken on windows. This is because the flag used doesn't exist and the symbol lookup in the test did not account for platform differences in name mangling. This commit fixes the flag and tests for rdynamic on windows. Test Plan: make TEST="rdynamic" on both x86 and x86_64 Reviewers: austin, thomie, bgamari Reviewed By: thomie, bgamari Subscribers: #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D1149 GHC Trac Issues: #9381 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 18 16:34:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Aug 2015 16:34:25 -0000 Subject: [GHC] #6037: Compile-time crash with sources with non-representable unicode characters In-Reply-To: <043.7207ef363a1d98123424aaa571c817fa@haskell.org> References: <043.7207ef363a1d98123424aaa571c817fa@haskell.org> Message-ID: <058.57b4337312c24b51c208a13e6003bf84@haskell.org> #6037: Compile-time crash with sources with non-representable unicode characters -------------------------------------+------------------------------------- Reporter: akio | Owner: snoyberg Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: T6037 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge * milestone: 7.12.1 => 7.10.3 Comment: Seems like this should go into a potential 7.10.3 if one happens. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 18 16:35:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Aug 2015 16:35:33 -0000 Subject: [GHC] #10762: On Windows, out-of-codepage characters can cause GHC build to fail In-Reply-To: <047.594293f39928454a6845b64e2efaf718@haskell.org> References: <047.594293f39928454a6845b64e2efaf718@haskell.org> Message-ID: <062.8c6cf1021d2c63b1f6c9c50693ecec5a@haskell.org> #10762: On Windows, out-of-codepage characters can cause GHC build to fail ---------------------------------+----------------------------------------- Reporter: snoyberg | Owner: snoyberg Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6037 | Differential Revisions: ---------------------------------+----------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 18 16:37:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Aug 2015 16:37:38 -0000 Subject: [GHC] #10549: floatExpr tick break<2> In-Reply-To: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> References: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> Message-ID: <066.ddfbdc974c6740e01e2e23503b9a2751@haskell.org> #10549: floatExpr tick break<2> -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T10549 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1128 -------------------------------------+------------------------------------- Comment (by NeilMitchell): I ran into this again and reduced it to something fairly different, and quite a lot simpler. You may want to incorporate the new example as an additional test case: {{{ {-# OPTIONS_GHC -O #-} module Main(main) where import GHC.Exts main = print 1 go (Ptr a) = a }}} Note the revised test case only requires GHC, not ByteString etc. With GHC 7.10.2, running runhaskell over it gives: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for i386-unknown-mingw32): floatExpr tick break<1>() }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 18 16:39:56 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Aug 2015 16:39:56 -0000 Subject: [GHC] #10775: Enable PolyKinds in GHC.Generics In-Reply-To: <050.1fb49e8a4f9e9ff5b73b6dbae85f944e@haskell.org> References: <050.1fb49e8a4f9e9ff5b73b6dbae85f944e@haskell.org> Message-ID: <065.ac8a68f6395de2c9ba437b6bdf12b7b7@haskell.org> #10775: Enable PolyKinds in GHC.Generics -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9766 | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by RyanGlScott): * blockedby: => 9766 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 18 16:48:08 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Aug 2015 16:48:08 -0000 Subject: [GHC] #10762: On Windows, out-of-codepage characters can cause GHC build to fail In-Reply-To: <047.594293f39928454a6845b64e2efaf718@haskell.org> References: <047.594293f39928454a6845b64e2efaf718@haskell.org> Message-ID: <062.0e067e76ea64776622055f26fbdd0c55@haskell.org> #10762: On Windows, out-of-codepage characters can cause GHC build to fail ---------------------------------+----------------------------------------- Reporter: snoyberg | Owner: snoyberg Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6037 | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by snoyberg): Thanks Ben for the merges. I had plans for one more potential change: setting up some environment variable that is respected by GHC on Windows to override the code page for stdout and stderr. Use case: capturing output from GHC in a build tool. My questions are: 1. Any objection to this in principle? 2. Do you want a new ticket opened for that? 3. Any thoughts on the environment variable? I was thinking about just reusing LANG and checking for a value ending in .UTF-8 so that the same code could be used on Windows and non-Windows for setting the environment variable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 18 17:53:35 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Aug 2015 17:53:35 -0000 Subject: [GHC] #9381: Implement -rdynamic In-Reply-To: <056.1019797b6ed554879c40e702f4d5c1f2@haskell.org> References: <056.1019797b6ed554879c40e702f4d5c1f2@haskell.org> Message-ID: <071.c0e2e0661d94a49d0ed33d30142eddec@haskell.org> #9381: Implement -rdynamic -------------------------------------+------------------------------------- Reporter: | Owner: Phyx- facundo.dominguez | Type: feature request | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7015 | Differential Revisions: Phab:D1149 -------------------------------------+------------------------------------- Changes (by Phyx-): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 18 18:04:17 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Aug 2015 18:04:17 -0000 Subject: [GHC] #10777: Overlong linker arguments on Windows leads to broken builds with confusing error messages In-Reply-To: <047.046a9f83230d0273c9346cd501403845@haskell.org> References: <047.046a9f83230d0273c9346cd501403845@haskell.org> Message-ID: <062.d6083e5f8c3db07cff0701d116dc8b94@haskell.org> #10777: Overlong linker arguments on Windows leads to broken builds with confusing error messages -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #8596 #9685 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by Phyx-): * related: => #8596 #9685 Comment: The limits are a bit all over the place. For the record: - The maximum command line length for the CreateProcess function is 32767 characters. This limitation comes from the UNICODE_STRING structure. CreateProcess is the core function for creating processes, so if you are talking directly to Win32, then that's the only limit you have to worry about. But if you are reaching CreateProcess by some other means, then the path you travel through may have other limits. - If you are using the CMD.EXE command processor, then you are also subject to the 8192 character command line length limit imposed by CMD.EXE. - If you are using the ShellExecute/Ex function, then you become subject to the INTERNET_MAX_URL_LENGTH (around 2048) command line length limit imposed by the ShellExecute/Ex functions. (If you are running on Windows 95, then the limit is only MAX_PATH.) [1] http://blogs.msdn.com/b/oldnewthing/archive/2003/12/10/56028.aspx [2] https://support.microsoft.com/en-us/kb/830473 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 18 18:05:08 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Aug 2015 18:05:08 -0000 Subject: [GHC] #8596: Add support for "reponse files" to workaround Windows command line length limitations In-Reply-To: <047.4af16120e3d32bd0dd2986d2dd5dd2de@haskell.org> References: <047.4af16120e3d32bd0dd2986d2dd5dd2de@haskell.org> Message-ID: <062.0257471fa85604f238187079375592a4@haskell.org> #8596: Add support for "reponse files" to workaround Windows command line length limitations -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10777 #9685 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by Phyx-): * related: => #10777 #9685 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 18 21:53:31 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Aug 2015 21:53:31 -0000 Subject: [GHC] #10775: Enable PolyKinds in GHC.Generics In-Reply-To: <050.1fb49e8a4f9e9ff5b73b6dbae85f944e@haskell.org> References: <050.1fb49e8a4f9e9ff5b73b6dbae85f944e@haskell.org> Message-ID: <065.91095b8290f91ee131c3cad0020fab21@haskell.org> #10775: Enable PolyKinds in GHC.Generics -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by dreixel): * blockedby: 9766 => Comment: This doesn't need to depend on #9766. This is a small change that can be done on its own. Go for it, I'd say :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 19 02:41:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Aug 2015 02:41:10 -0000 Subject: [GHC] #10778: GHC doesn't infer all constrains In-Reply-To: <046.c3c6007a301d4e9f2bfd6528e390abd4@haskell.org> References: <046.c3c6007a301d4e9f2bfd6528e390abd4@haskell.org> Message-ID: <061.7276300fe3ce3ff423269fac42127b10@haskell.org> #10778: GHC doesn't infer all constrains -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): I don't see a functional dependency on your `Container` class. Is there supposed to be one? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 19 11:01:39 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Aug 2015 11:01:39 -0000 Subject: [GHC] #10779: .so files in 64-bit Debian builds are 4% larger than they have to be Message-ID: <045.450bda01d4ecd6d42c485573e682c5ca@haskell.org> #10779: .so files in 64-bit Debian builds are 4% larger than they have to be -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Build | Version: 7.10.2 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- For some reason, all .so files from the Debian builds at https://www.haskell.org/ghc/download_ghc_7_10_2#x86_64linux are larger then the equivalent files in the CentOS build, my own (Ubuntu) build, or hvr's ppa build. For example, comparing the size of `libHSfilepath-1.4.0.0 -KsGE6pHE5eZHSN90ZVax6A-ghc7.10.2.so`, after installation (i.e. after strip --strip-unneeded): ||= build =||= size (bytes) =|| || Debian || 128520 || || Centos || 124280 || || hvr ppa || 123112 || || my own || 123112 || Maybe the linker or strip utility on the Debian system where GHC releases are built should be upgraded. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 19 11:08:59 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Aug 2015 11:08:59 -0000 Subject: [GHC] #10780: Weak reference is still alive if key is alive, but weak reference itself not reachable Message-ID: <043.34f0e80514e6e63f06c255266bbd2680@haskell.org> #10780: Weak reference is still alive if key is alive, but weak reference itself not reachable -------------------------------------+------------------------------------- Reporter: atze | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.2 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- We've been running into some unexpected behavior with weak references. The use case it hackage package HMap, which is a (heterogenous, but that is besides the point) map from keys to values. Since there is no way to enumerate all elements in the map, there is no way to obtain a value for a key if the key is dead. As an optimization, I therefore used weak references to the values in the map, such that if the key dies, then the value is also dead. I was under the impression that a weak reference is alive if: (1): The key is still alive AND (2): The weak reference itself is alive (i.e. reachable from root set) However, the actual behavior is that a weak reference is alive if (1), (2) does not matter. Hence, the weak references here actually create a space leak, because an alive key will keep all values in all maps that it was ever used in alive. I think it would be desirable, to change the behavior to (1) AND (2), instead of just (1). This would prevent space leaks in this use case instead of creating them. Or would this cause problems in other use cases? See also: https://github.com/atzeus/HMap/issues/5#issuecomment-132538324 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 19 11:54:06 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Aug 2015 11:54:06 -0000 Subject: [GHC] #1851: "make install-strip" should work In-Reply-To: <044.55b2dd35d7abad74f0ebfed90c4f828d@haskell.org> References: <044.55b2dd35d7abad74f0ebfed90c4f828d@haskell.org> Message-ID: <059.84b263f6c23431a9bfaf21dc28008e1b@haskell.org> #1851: "make install-strip" should work -------------------------------------+------------------------------------- Reporter: igloo | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * owner: => thomie -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 19 11:56:05 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Aug 2015 11:56:05 -0000 Subject: [GHC] #9087: Executables in the Linux binaries are not stripped In-Reply-To: <045.32e06e6ec3c181db27d068784d01610c@haskell.org> References: <045.32e06e6ec3c181db27d068784d01610c@haskell.org> Message-ID: <060.77739ad6a64e60a5ba1cfb017c0bc615@haskell.org> #9087: Executables in the Linux binaries are not stripped -------------------------------------+------------------------------------- Reporter: refold | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #1851 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * owner: => thomie * related: => #1851 Comment: .a files are not stripped either, though .so files are (using `--strip- unneeded`). I think this is a Cabal bug. I'm working on a fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 19 12:17:18 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Aug 2015 12:17:18 -0000 Subject: [GHC] #10779: .so files in 64-bit Debian builds are 4% larger than they have to be In-Reply-To: <045.450bda01d4ecd6d42c485573e682c5ca@haskell.org> References: <045.450bda01d4ecd6d42c485573e682c5ca@haskell.org> Message-ID: <060.9615e0677d3bc5dfc6872d7310d9b449@haskell.org> #10779: .so files in 64-bit Debian builds are 4% larger than they have to be -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Build System | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): I built these on an up-to-date Debian 7 container. The fact that the CentOS build is of similar size to the other builds suggests that the problem isn't one of toolchain version (as CentOS packages are as old as the hills). It would be nice to know which section(s) in the object file are the cause of this bloat. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 19 14:58:35 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Aug 2015 14:58:35 -0000 Subject: [GHC] #10779: .so files in 64-bit Debian builds are 4% larger than they have to be In-Reply-To: <045.450bda01d4ecd6d42c485573e682c5ca@haskell.org> References: <045.450bda01d4ecd6d42c485573e682c5ca@haskell.org> Message-ID: <060.e91da89aea54ca76956dd670a391ef73@haskell.org> #10779: .so files in 64-bit Debian builds are 4% larger than they have to be -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Build System | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Below, filepath-ubuntu.so is from hvr's ppa build of ghc-7.10.2 (exact file mentioned above), filepath-debian.so is from the Debian download. {{{ $ size -A filepath-ubuntu.so filepath-debian.so filepath-ubuntu.so : section size addr .note.gnu.build-id 36 400 .gnu.hash 2564 440 .dynsym 8976 3008 .dynstr 26101 11984 .gnu.version 748 38086 .gnu.version_r 32 38840 .rela.dyn 12816 38872 .rela.plt 96 51688 .init 26 51784 .plt 80 51824 .text 60569 51904 .fini 9 112476 .rodata 278 112488 .eh_frame 4 112768 .init_array 8 2210792 .fini_array 8 2210800 .jcr 8 2210808 .dynamic 624 2210816 .got 400 2211440 .got.plt 56 2211840 .data 6624 2211896 .bss 8 2218520 Total 120071 filepath-debian.so : section size addr .note.gnu.build-id 36 400 .hash 2556 440 .gnu.hash 2564 3000 .dynsym 8976 5568 .dynstr 26101 14544 .gnu.version 748 40646 .gnu.version_r 32 41400 .rela.dyn 12816 41432 .rela.plt 72 54248 .init 14 54320 .plt 64 54336 .text 60596 54400 .fini 9 114996 .rodata 278 115008 .eh_frame_hdr 20 115288 .eh_frame 68 115312 .init_array 8 2215936 .fini_array 8 2215944 .jcr 8 2215952 .dynamic 640 2215960 .got 400 2216600 .got.plt 48 2217000 .data 6624 2217048 .bss 8 2223672 .comment 39 0 Total 122733 }}} filepath-debian.so contains additional `.hash`, `.eh_frame_hdr` and `.comment` sections. After removing those, the `size` utility reports a similar file size as it does for filepath-ubuntu.so: {{{ $ strip -R .hash -R .eh_frame_hdr -R .comment filepath-debian.so $ size filepath-debian.so text data bss dec hex filename 112394 7736 8 120138 1d54a filepath-debian.so }}} But the file did not get much smaller. I don't understand why not. {{{ $ wc -c filepath-debian.so 128456 filepath-debian.so }}} My system: {{{ $ ld --version # Binutils also provides `size` and `strip`. GNU ld (GNU Binutils for Ubuntu) 2.24 $ gcc --version gcc (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 19 15:09:39 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Aug 2015 15:09:39 -0000 Subject: [GHC] #10779: .so files in 64-bit Debian builds are 4% larger than they have to be In-Reply-To: <045.450bda01d4ecd6d42c485573e682c5ca@haskell.org> References: <045.450bda01d4ecd6d42c485573e682c5ca@haskell.org> Message-ID: <060.1bb86fd3ffb831c2826f6c5f0724df80@haskell.org> #10779: .so files in 64-bit Debian builds are 4% larger than they have to be -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Build System | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Note the following differences below (I don't know what any of this means): * filepath-debian.so contains the program header `GNU_EH_FRAME` instead of `GNU_RELRO`. * filepath-debian.so is missing the section to segment mapping for segment 05 (.init_array .fini_array .jcr .dynamic .got). {{{ $ readelf --program-headers filepath-ubuntu.so Elf file type is DYN (Shared object file) Entry point 0xcac0 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x000000000001b884 0x000000000001b884 R E 200000 LOAD 0x000000000001bbe8 0x000000000021bbe8 0x000000000021bbe8 0x0000000000001e30 0x0000000000001e38 RW 200000 DYNAMIC 0x000000000001bc00 0x000000000021bc00 0x000000000021bc00 0x0000000000000270 0x0000000000000270 RW 8 NOTE 0x0000000000000190 0x0000000000000190 0x0000000000000190 0x0000000000000024 0x0000000000000024 R 4 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RW 10 GNU_RELRO 0x000000000001bbe8 0x000000000021bbe8 0x000000000021bbe8 0x0000000000000418 0x0000000000000418 R 1 Section to Segment mapping: Segment Sections... 00 .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame 01 .init_array .fini_array .jcr .dynamic .got .got.plt .data .bss 02 .dynamic 03 .note.gnu.build-id 04 05 .init_array .fini_array .jcr .dynamic .got }}} {{{ $ readelf --program-headers filepath-debian.so Elf file type is DYN (Shared object file) Entry point 0xd480 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x000000000001c2b4 0x000000000001c2b4 R E 200000 LOAD 0x000000000001d000 0x000000000021d000 0x000000000021d000 0x0000000000001e38 0x0000000000001e40 RW 200000 DYNAMIC 0x000000000001d018 0x000000000021d018 0x000000000021d018 0x0000000000000280 0x0000000000000280 RW 8 NOTE 0x0000000000000190 0x0000000000000190 0x0000000000000190 0x0000000000000024 0x0000000000000024 R 4 GNU_EH_FRAME 0x000000000001c258 0x000000000001c258 0x000000000001c258 0x0000000000000014 0x0000000000000014 R 4 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RW 8 Section to Segment mapping: Segment Sections... 00 .note.gnu.build-id .hash .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame 01 .init_array .fini_array .jcr .dynamic .got .got.plt .data .bss 02 .dynamic 03 .note.gnu.build-id 04 .eh_frame_hdr 05 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 19 16:14:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Aug 2015 16:14:08 -0000 Subject: [GHC] #8335: Create more specialized entries to GC In-Reply-To: <048.b95f2f48d387537ed648bf2e9895d80e@haskell.org> References: <048.b95f2f48d387537ed648bf2e9895d80e@haskell.org> Message-ID: <063.67257d9cd0c3d97dc8aae252e85a7812@haskell.org> #8335: Create more specialized entries to GC -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari Comment: There should be a check in the stack allocator to catch this case. It's possible that this isn't firing. I'll have a look at this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 19 16:45:37 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Aug 2015 16:45:37 -0000 Subject: [GHC] #10781: Qualified use of undefined name starting with underscore considered a hole Message-ID: <048.05d55f91f7c6a759b2d92132b817f2bc@haskell.org> #10781: Qualified use of undefined name starting with underscore considered a hole -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: holes | Operating System: Unknown/Multiple qualified | Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- `Foo._name` is reported as an error `..: Found hole ...`. It doesn't make much sense to use qualified holes like that, so it is not useful to treat such qualified names as holes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 19 16:54:42 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Aug 2015 16:54:42 -0000 Subject: [GHC] #10778: GHC doesn't infer all constrains In-Reply-To: <046.c3c6007a301d4e9f2bfd6528e390abd4@haskell.org> References: <046.c3c6007a301d4e9f2bfd6528e390abd4@haskell.org> Message-ID: <061.67b6129d542f3aa33af75626626d144f@haskell.org> #10778: GHC doesn't infer all constrains -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by danilo2): No, But there are the GADTs constraints: {{{ IndexOf a cont ~ idx, ElementByIdx idx cont ~ a, Measurable cont }}} So {{{idx}}} is always result of {{{IndexOf a cont}}}. Is this information not enough for Haskell? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 19 17:05:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Aug 2015 17:05:23 -0000 Subject: [GHC] #10778: GHC doesn't infer all constrains In-Reply-To: <046.c3c6007a301d4e9f2bfd6528e390abd4@haskell.org> References: <046.c3c6007a301d4e9f2bfd6528e390abd4@haskell.org> Message-ID: <061.6501c3fb3ab81af82c73e6b430f2621f@haskell.org> #10778: GHC doesn't infer all constrains -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Ah -- I see now. Yes, this might be reasonable. Curious to see what Simon thinks, after he returns from holiday. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 19 18:38:40 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Aug 2015 18:38:40 -0000 Subject: [GHC] #7285: mkWeakMVar is non-compositional In-Reply-To: <044.e6c10f44e589834510279a56d62e7d7d@haskell.org> References: <044.e6c10f44e589834510279a56d62e7d7d@haskell.org> Message-ID: <059.9c89127a7e2750351f7233e09e4bbd72@haskell.org> #7285: mkWeakMVar is non-compositional -------------------------------------+------------------------------------- Reporter: edsko | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): The libraries proposal mentioned in comment:7: https://mail.haskell.org/pipermail/libraries/2014-November/024143.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 19 19:22:58 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Aug 2015 19:22:58 -0000 Subject: [GHC] #10780: Weak reference is still alive if key is alive, but weak reference itself not reachable In-Reply-To: <043.34f0e80514e6e63f06c255266bbd2680@haskell.org> References: <043.34f0e80514e6e63f06c255266bbd2680@haskell.org> Message-ID: <058.f6cf83c08902c3a6c9e5875abb6ac6ec@haskell.org> #10780: Weak reference is still alive if key is alive, but weak reference itself not reachable -------------------------------------+------------------------------------- Reporter: atze | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => wontfix Comment: This is working as intended, see http://research.microsoft.com/apps/pubs/default.aspx?id=67497 The paper includes an implementation of a memo table, which should help with the situation in HMap. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 19 19:33:18 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Aug 2015 19:33:18 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.e31e1a5ced6836a80aea146f2ca2c7f7@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonmar): I talked with @bgamari about this a bit today. What I think you're seeing in the above data is entries of *indirections*, not blackholes. Indirections and blackholes look the same, except that in a true black hole, the indirectee points to a TSO rather than a value. Looking for the cases where the indirectee is a TSO will tell you how many times we get blocked on a black hole. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 19 19:48:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Aug 2015 19:48:15 -0000 Subject: [GHC] #4243: Make a proper options parser for the RTS In-Reply-To: <044.6ea5654174cc0120653bc110fe1a703c@haskell.org> References: <044.6ea5654174cc0120653bc110fe1a703c@haskell.org> Message-ID: <059.4d71c42d37255bf9ec7c9c7aec097eaf@haskell.org> #4243: Make a proper options parser for the RTS -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 7535 Related Tickets: #9839 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by carlostome): * owner: carlostome => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 19 20:20:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Aug 2015 20:20:10 -0000 Subject: [GHC] #10782: Existential variables not scoped? Message-ID: <047.163aa6e21fe23b588fdda5e44a010081@haskell.org> #10782: Existential variables not scoped? -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I was looking into scoping of type variables, and it looks to me that type-checking the introduction of existentials (that is, checking a GADT pattern-match) doesn't extend the type environment. I doubt there's any way to tickle this bug. But the existential skolems don't seem to be added to the `tcl_tyvars` field of the `TcLclEnv`, which means that inner quantification, should uniques collide(!), might do the wrong thing in `quantifyTyVars`. To be clear, I don't wish the variables actually to scope in Haskell source, just for GHC to remember that the internal variables are in scope, to return from `tcGetGlobalTyVars`. Is my analysis wrong somewhere? Do we just assume that uniques being unique will take care of this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 19 23:12:41 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Aug 2015 23:12:41 -0000 Subject: [GHC] #10672: checkProddableBlock crash during Template Haskell linking In-Reply-To: <045.04cee7c60b130b0ccc29791ed61c4f5f@haskell.org> References: <045.04cee7c60b130b0ccc29791ed61c4f5f@haskell.org> Message-ID: <060.014beb04d28a02cf4669fc813405066b@haskell.org> #10672: checkProddableBlock crash during Template Haskell linking -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #9297 #10563 | Differential Revisions: #8237 #9907 | -------------------------------------+------------------------------------- Comment (by ezyang): Hello lukexi, The problem is that your binary contains a section which (1) is pointed to by relocations, and (2) GHC doesn't understand. The pre-7.10.x error is better because it looks like to make your code work we really do need to understand the relocation. (We could paper over the problem by simply skipping relocations in sections we don't understand, but it is quite likely that you will get some even more bizarre error.) Can you run your test program with `+RTS -Dl` (debug RTS) and tell us exactly what section is unknown? Edward -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 19 23:14:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Aug 2015 23:14:27 -0000 Subject: [GHC] #10563: GHC 7.10.1 Win7 x86_64 crash when building reflex-dom-0.1.1 In-Reply-To: <044.865cad2cae7a0515bb63b8ae4cd3b513@haskell.org> References: <044.865cad2cae7a0515bb63b8ae4cd3b513@haskell.org> Message-ID: <059.89618bf3cfaea48ca7aa1d11990cc5cc@haskell.org> #10563: GHC 7.10.1 Win7 x86_64 crash when building reflex-dom-0.1.1 -------------------------------------+------------------------------------- Reporter: tejon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): Hello, can you run your program with `+RTS -Dl` with the debug RTS and report any Unknown PEi386 section name errors? It's probably exception handling. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 19 23:18:12 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Aug 2015 23:18:12 -0000 Subject: [GHC] #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows In-Reply-To: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> References: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> Message-ID: <066.6bf0cedee78393cc205b10705f255a53@haskell.org> #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows -------------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7103, #10051, | Differential Revisions: Phab:D671 #7056, #8546 | -------------------------------------+------------------------------------- Changes (by ezyang): * owner: Phyx- => * status: closed => new * resolution: fixed => Comment: I am reopening this ticket, because by suppressing these errors we have opened up users to a more pernicious situation: GHC silently ignores a section it doesn't understand (failing to map it into memory) when a program ACTUALLY needs it to function. Previously, it was pretty obvious that something bad had happened and it was because GHC didn't support a section, but now the errors can be a lot more obscure, e.g. #10672 and #10563. Is there any reason we can't take an alternate approach, where by default we attempt to map in ALL sections in an object file, except ones we've specifically blacklisted? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 19 23:33:07 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Aug 2015 23:33:07 -0000 Subject: [GHC] #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows In-Reply-To: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> References: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> Message-ID: <066.91508e526d619dae06f3443eebbae3bf@haskell.org> #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows -------------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7103, #10051, | Differential Revisions: Phab:D671 #7056, #8546 | -------------------------------------+------------------------------------- Changes (by Phyx-): * cc: Phyx- (added) Comment: I have been trying something similar, but then I encountered another error: `unhandled PEi386 relocation type 3`. Looking at the code there is indeed no case for relocation type 3 which unless I'm mistaken is: IMAGE_REL_AMD64_ADDR32NB 0x0003 The 32-bit address without an image base (RVA). But curiously while trying to understand what the linker is doing (and I may have the wrong idea since I'm new to this part) I see under the `x86_64` cases this `case 17: /* R_X86_64_32S */`. However in the PE doc I can't find any relocation type `0x0011`. So am I looking at the wrong place or should this have been `0x0003`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 19 23:39:59 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Aug 2015 23:39:59 -0000 Subject: [GHC] #10756: Allow users to indicate inaccessible patterns In-Reply-To: <044.44fc866587983798150a57353bc7bdbd@haskell.org> References: <044.44fc866587983798150a57353bc7bdbd@haskell.org> Message-ID: <059.1653b6ba340f15ee9fc3f6fbd8e69154@haskell.org> #10756: Allow users to indicate inaccessible patterns -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by YitzGale): * cc: gale@? (added) Comment: I propose a modification: that {{{impossible}}} not become a full-fledged keyword, but rather that it only be given special meaning in the context of a pattern expression. I leave as an open question how this should work in a pattern guard. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 20 01:25:47 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Aug 2015 01:25:47 -0000 Subject: [GHC] #10563: GHC 7.10.1 Win7 x86_64 crash when building reflex-dom-0.1.1 In-Reply-To: <044.865cad2cae7a0515bb63b8ae4cd3b513@haskell.org> References: <044.865cad2cae7a0515bb63b8ae4cd3b513@haskell.org> Message-ID: <059.8f3b90f002a708a6a8c8f2d12fbc3347@haskell.org> #10563: GHC 7.10.1 Win7 x86_64 crash when building reflex-dom-0.1.1 -------------------------------------+------------------------------------- Reporter: tejon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by tejon): The program in question is GHC. Is one of the standard `build.mk` configurations appropriate for this? I don't know if I'm dealing with stage 1 or 2, or something else here... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 20 02:43:54 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Aug 2015 02:43:54 -0000 Subject: [GHC] #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows In-Reply-To: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> References: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> Message-ID: <066.9f1a5460f38e63d2090a59d56e6a567d@haskell.org> #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows -------------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7103, #10051, | Differential Revisions: Phab:D671 #7056, #8546 | -------------------------------------+------------------------------------- Changes (by ezyang): * cc: igloo (added) Comment: Ian Lyangh would be able to say better, having authored the patch, but what I think happened was, because the PE spec doesn't actually say how to process relocations, the code was written by cross-referencing against relocations in ELF. But it does look like R_X86_64_32S was given the wrong constant... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 20 03:30:30 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Aug 2015 03:30:30 -0000 Subject: [GHC] #10756: Allow users to indicate inaccessible patterns In-Reply-To: <044.44fc866587983798150a57353bc7bdbd@haskell.org> References: <044.44fc866587983798150a57353bc7bdbd@haskell.org> Message-ID: <059.fe49dbfddfcd5c3b76074f322643599d@haskell.org> #10756: Allow users to indicate inaccessible patterns -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): But the only way to bind a variable is in a pattern. That's why it must become a full keyword, in my view. Or have I missed something? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 20 08:34:39 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Aug 2015 08:34:39 -0000 Subject: [GHC] #10780: Weak reference is still alive if key is alive, but weak reference itself not reachable In-Reply-To: <043.34f0e80514e6e63f06c255266bbd2680@haskell.org> References: <043.34f0e80514e6e63f06c255266bbd2680@haskell.org> Message-ID: <058.648606f80735655ff58f78a451b04ede@haskell.org> #10780: Weak reference is still alive if key is alive, but weak reference itself not reachable -------------------------------------+------------------------------------- Reporter: atze | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by atze): Thanks! The paper indeed discusses and gives a nice solution to this. Subtle stuff :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 20 12:35:03 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Aug 2015 12:35:03 -0000 Subject: [GHC] #10672: checkProddableBlock crash during Template Haskell linking In-Reply-To: <045.04cee7c60b130b0ccc29791ed61c4f5f@haskell.org> References: <045.04cee7c60b130b0ccc29791ed61c4f5f@haskell.org> Message-ID: <060.a3cc96d956eb5b9801d014c16f33643f@haskell.org> #10672: checkProddableBlock crash during Template Haskell linking -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #9297 #10563 | Differential Revisions: #8237 #9907 | -------------------------------------+------------------------------------- Comment (by lukexi): Hi Edward, thanks for the reply! Just to be sure, do you mean compiling a GHC with GhcDebugged=YES and then using cabal build --ghc-options="+RTS -Dl"? Luke -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 20 13:54:09 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Aug 2015 13:54:09 -0000 Subject: [GHC] #8484: Compile-time panic In-Reply-To: <045.cfbefb278865add04d816ec807a8ca09@haskell.org> References: <045.cfbefb278865add04d816ec807a8ca09@haskell.org> Message-ID: <060.b91c4ab68ad01bae539064bb4e1379f3@haskell.org> #8484: Compile-time panic -------------------------------------+------------------------------------- Reporter: Taymon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by zilinc): * status: closed => new * resolution: worksforme => Comment: {{{ zilinc at zilinc-dell-xps:~/research/haskell/panic-parsing$ cabal build --with-ghc=ghc-7.8.4 Building panic-parsing-0.1.0.0... Preprocessing executable 'panic-parsing' for panic-parsing-0.1.0.0... ghc: panic! (the 'impossible' happened) (GHC version 7.8.4 for x86_64-unknown-linux): While parsing "/home/zilinc/research/haskell/panic-parsing/.cabal- sandbox/x86_64-linux-ghc-7.10.2-packages.conf.d/package.cache": demandInput: not enough bytes Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} To reproduce it, I did: * create a new cabal package (`cabal init`), with a sandbox (`cabal sandbox init`) * create a Main module, can be as simple as: {{{#!hs module Main where main = putStrLn "done" }}} * create a `cabal.config` file, with {{{ with-compiler: ghc-7.10.2 with-hc-pkg: ghc-pkg-7.10.2 }}} * `cabal configure && cabal build`. everything should be okay so far * do `cabal build --with-ghc=ghc-7.8.4`, then I got panic What I did may not be correct, but either way `impossible` should not happen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 20 14:15:41 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Aug 2015 14:15:41 -0000 Subject: [GHC] #8484: Compile-time panic In-Reply-To: <045.cfbefb278865add04d816ec807a8ca09@haskell.org> References: <045.cfbefb278865add04d816ec807a8ca09@haskell.org> Message-ID: <060.0e996ce3c82253755bd5d5bebe94da2b@haskell.org> #8484: Compile-time panic -------------------------------------+------------------------------------- Reporter: Taymon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Ideally the package cache format would include a version number so we can fail more gracefully (if it doesn't already). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 20 17:14:57 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Aug 2015 17:14:57 -0000 Subject: [GHC] #10672: checkProddableBlock crash during Template Haskell linking In-Reply-To: <045.04cee7c60b130b0ccc29791ed61c4f5f@haskell.org> References: <045.04cee7c60b130b0ccc29791ed61c4f5f@haskell.org> Message-ID: <060.676902f7130e392f4de410dd578b9088@haskell.org> #10672: checkProddableBlock crash during Template Haskell linking -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #9297 #10563 | Differential Revisions: #8237 #9907 | -------------------------------------+------------------------------------- Comment (by ezyang): Yeah, something like `make re2 GhcDebugged=YES`. But it looks like the sections in question are `.gcc_except_table` and `.text$_ZN21btBroadphaseInterfaceD1Ev`. So two things we need to do: 1. Handle the exception table correctly 2. Match against the PREFIX so that anything starting with `.text` is loaded as a text segment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 20 17:29:21 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Aug 2015 17:29:21 -0000 Subject: [GHC] #10756: Allow users to indicate inaccessible patterns In-Reply-To: <044.44fc866587983798150a57353bc7bdbd@haskell.org> References: <044.44fc866587983798150a57353bc7bdbd@haskell.org> Message-ID: <059.f2685372ac9168eb3c8a54343ce9e3bc@haskell.org> #10756: Allow users to indicate inaccessible patterns -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by YitzGale): Replying to [comment:7 goldfire]: > But the only way to bind a variable is in a pattern. That's why it must become a full keyword, in my view. Or have I missed something? Sorry, to be more explicit - `impossible` only has special meaning in pattern expressions, and only '''after''' the ''var'' term, which always occurs in first position in pattern expressions that contain it. We can simplify that to say that `impossible` never has special meaning in first position in a pattern expression in any case, since anyway that never makes sense. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 20 18:05:11 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Aug 2015 18:05:11 -0000 Subject: [GHC] #10783: Partial type signatures should work with pattern synonym signatures Message-ID: <049.9210bbc1c425a4fe689a15bfe5ab9550@haskell.org> #10783: Partial type signatures should work with pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE PatternSynonyms #-} pattern MyJust :: _ pattern MyJust a = Just a }}} GHC can correctly infer the type for the pattern without the type signature so (to me) it is unexpected that this inferred type is not reported to me when using partial type signatures. It just seems to not be implemented currently. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 20 18:06:09 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Aug 2015 18:06:09 -0000 Subject: [GHC] #10783: Partial type signatures should work in pattern synonym signatures (was: Partial type signatures should work with pattern synonym signatures) In-Reply-To: <049.9210bbc1c425a4fe689a15bfe5ab9550@haskell.org> References: <049.9210bbc1c425a4fe689a15bfe5ab9550@haskell.org> Message-ID: <064.f3c4d44e23c6eccf212ac970940c78cf@haskell.org> #10783: Partial type signatures should work in pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 21 00:26:14 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Aug 2015 00:26:14 -0000 Subject: [GHC] #10733: Improving the error message for type variable ambiguity In-Reply-To: <049.e68ae3d7f8aaef94b3cdeb692d3e5ac5@haskell.org> References: <049.e68ae3d7f8aaef94b3cdeb692d3e5ac5@haskell.org> Message-ID: <064.981db405b3cc2a48a83ed7677de31f62@haskell.org> #10733: Improving the error message for type variable ambiguity -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: kanetw Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by kanetw): * owner: => kanetw -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 21 01:05:07 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Aug 2015 01:05:07 -0000 Subject: [GHC] #10733: Improving the error message for type variable ambiguity In-Reply-To: <049.e68ae3d7f8aaef94b3cdeb692d3e5ac5@haskell.org> References: <049.e68ae3d7f8aaef94b3cdeb692d3e5ac5@haskell.org> Message-ID: <064.2d437aaa10f0a21b9b8231dd10107193@haskell.org> #10733: Improving the error message for type variable ambiguity -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: kanetw Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Thanks for taking this on @kanetw. The code to change should all be in !TcErrors. Shout if you want advice! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 21 04:49:06 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Aug 2015 04:49:06 -0000 Subject: [GHC] #8596: Add support for "reponse files" to workaround Windows command line length limitations In-Reply-To: <047.4af16120e3d32bd0dd2986d2dd5dd2de@haskell.org> References: <047.4af16120e3d32bd0dd2986d2dd5dd2de@haskell.org> Message-ID: <062.bff7d68859f7e4ca5f25a010caf735c3@haskell.org> #8596: Add support for "reponse files" to workaround Windows command line length limitations -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: snoyberg Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10777 #9685 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by snoyberg): * owner: => snoyberg -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 21 04:49:12 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Aug 2015 04:49:12 -0000 Subject: [GHC] #10777: Overlong linker arguments on Windows leads to broken builds with confusing error messages In-Reply-To: <047.046a9f83230d0273c9346cd501403845@haskell.org> References: <047.046a9f83230d0273c9346cd501403845@haskell.org> Message-ID: <062.a59033b787559b51d72a84b6a621c6dc@haskell.org> #10777: Overlong linker arguments on Windows leads to broken builds with confusing error messages -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: snoyberg Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #8596 #9685 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by snoyberg): * owner: => snoyberg -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 21 04:49:56 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Aug 2015 04:49:56 -0000 Subject: [GHC] #8596: Add support for "reponse files" to workaround Windows command line length limitations In-Reply-To: <047.4af16120e3d32bd0dd2986d2dd5dd2de@haskell.org> References: <047.4af16120e3d32bd0dd2986d2dd5dd2de@haskell.org> Message-ID: <062.a1b1ce39d6d9cf52cd3b7a0b25095039@haskell.org> #8596: Add support for "reponse files" to workaround Windows command line length limitations -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: snoyberg Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10777 #9685 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by snoyberg): I've sent a diff for this: https://phabricator.haskell.org/D1158 Unfortunately, I haven't been successful yet at building GHC on Windows, so I haven't tested there yet. If someone who's experienced this problem has success building with that change, please report back. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 21 04:49:58 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Aug 2015 04:49:58 -0000 Subject: [GHC] #10777: Overlong linker arguments on Windows leads to broken builds with confusing error messages In-Reply-To: <047.046a9f83230d0273c9346cd501403845@haskell.org> References: <047.046a9f83230d0273c9346cd501403845@haskell.org> Message-ID: <062.4e9854e86a0e63c5cdb7bf1dd04a2a82@haskell.org> #10777: Overlong linker arguments on Windows leads to broken builds with confusing error messages -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: snoyberg Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #8596 #9685 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by snoyberg): I've sent a diff for this: https://phabricator.haskell.org/D1158 Unfortunately, I haven't been successful yet at building GHC on Windows, so I haven't tested there yet. If someone who's experienced this problem has success building with that change, please report back. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 21 06:46:14 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Aug 2015 06:46:14 -0000 Subject: [GHC] #10784: ghci crashed when ``-with-rtsopts=-A64m'' is specified Message-ID: <045.4d6d623b9a5e8ed91c57331a330e0ccc@haskell.org> #10784: ghci crashed when ``-with-rtsopts=-A64m'' is specified -------------------------------------------+------------------------------- Reporter: wangbj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+------------------------------- $ cat /tmp/t1.hs {-# OPTIONS -O2 -with-rtsopts=-A64m #-} main = putStrLn "hello, world!" wangbj at nuc ~/hs $ runghc /tmp/t1.hs ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): floatExpr tick break<0>() 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 Aug 21 07:34:39 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Aug 2015 07:34:39 -0000 Subject: [GHC] #10755: Add `MonadPlus IO` and `Alternative IO` instances In-Reply-To: <042.9475d11a3f91fa4e741f69ce0a266155@haskell.org> References: <042.9475d11a3f91fa4e741f69ce0a266155@haskell.org> Message-ID: <057.5de12fdf871f6180b5a5208cc3c516a1@haskell.org> #10755: Add `MonadPlus IO` and `Alternative IO` instances -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: Resolution: | Keywords: report- | impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1148 -------------------------------------+------------------------------------- Comment (by ekmett): I think the ideal situation would be to have `transformers` continue to export those instances conditional on the version of `base`. This would ensure that the maximal number of versions of `base` work with the maximal number of versions of `transformers`, rather than inducing an unneeded gate function on what works with what. These sorts of gotchas are the things that drive away users, so it is worth spending the time to get this right. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 21 07:43:51 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Aug 2015 07:43:51 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2310637=3A_Cannot_suppress_=22Warning?= =?utf-8?q?=3A_=7B-=23_SOURCE_=23-=7D_unnecessary_in_import_of__?= =?utf-8?b?4oCYQeKAmSI=?= In-Reply-To: <046.5119908e23481708e117e58b6fa1ab97@haskell.org> References: <046.5119908e23481708e117e58b6fa1ab97@haskell.org> Message-ID: <061.909987072cd960eeb1759fa2ac4f25c9@haskell.org> #10637: Cannot suppress "Warning: {-# SOURCE #-} unnecessary in import of ?A?" ---------------------------------+----------------------------------------- Reporter: phischu | Owner: rpglover64 Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Changes (by mpickering): * owner: => rpglover64 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 21 08:34:52 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Aug 2015 08:34:52 -0000 Subject: [GHC] #10784: ghci crashed when ``-with-rtsopts=-A64m'' is specified In-Reply-To: <045.4d6d623b9a5e8ed91c57331a330e0ccc@haskell.org> References: <045.4d6d623b9a5e8ed91c57331a330e0ccc@haskell.org> Message-ID: <060.bfcd25a7b32d8cbc3105966af19b1b28@haskell.org> #10784: ghci crashed when ``-with-rtsopts=-A64m'' is specified -------------------------------+------------------------------------------- Reporter: wangbj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #10549 | Differential Revisions: -------------------------------+------------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #10549 Old description: > $ cat /tmp/t1.hs > {-# OPTIONS -O2 -with-rtsopts=-A64m #-} > > main = putStrLn "hello, world!" > wangbj at nuc ~/hs $ runghc /tmp/t1.hs > ghc: panic! (the 'impossible' happened) > (GHC version 7.10.2 for x86_64-unknown-linux): > floatExpr tick break<0>() > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug New description: {{{ $ cat /tmp/t1.hs {-# OPTIONS -O2 -with-rtsopts=-A64m #-} main = putStrLn "hello, world!" wangbj at nuc ~/hs $ runghc /tmp/t1.hs ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): floatExpr tick break<0>() Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Comment: The problem is `-O2` in combination with runghc. The `-O2` should be ignored, but ghc-7.10.2 has a bug and it crashes instead. Fixed in #10549. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 21 10:52:31 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Aug 2015 10:52:31 -0000 Subject: [GHC] #10759: don't throw BlockedIndefinitelyOn... in main thread In-Reply-To: <044.e96ca394fd0ec7f5ab2bd63075d05667@haskell.org> References: <044.e96ca394fd0ec7f5ab2bd63075d05667@haskell.org> Message-ID: <059.ac139aa19546a93f578e29dc78215e2e@haskell.org> #10759: don't throw BlockedIndefinitelyOn... in main thread -------------------------------------+------------------------------------- Reporter: yokto | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => wontfix Comment: It's a tradeoff - if we made it so that the main thread never got `BlockedIndefinitely` exceptions, then we would never catch deadlock or infinite loops in the main thread. There's a workaround for the case above: {{{ t <- myThreadId newStablePtr t }}} will make the main thread impervious to `BlockedIndefinitely` exceptions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 21 12:12:17 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Aug 2015 12:12:17 -0000 Subject: [GHC] #10755: Add `MonadPlus IO` and `Alternative IO` instances In-Reply-To: <042.9475d11a3f91fa4e741f69ce0a266155@haskell.org> References: <042.9475d11a3f91fa4e741f69ce0a266155@haskell.org> Message-ID: <057.9d108e46eff4cf4e68bbb7a0b65f1683@haskell.org> #10755: Add `MonadPlus IO` and `Alternative IO` instances -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: Resolution: | Keywords: report- | impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1148 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: ross (added) Comment: While I don't want to cause unnecessary pain for users, I have to wonder about the placement of the instances in `transformers`. Currebtly, they're located in `Control.Monad.Trans.Error`, which has been deprecated for a while. If users want to backport these new `IO` instances in their code, they'll have to reach for a module which GHC will warn is deprecated, which doesn't feel satisfying. Perhaps we could move the orphan instances to a different module in `transformers`, reexport it from `Control.Monad.Trans.Error`, and tell users to use the new module from here on out for conpatibility purposes? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 21 12:47:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Aug 2015 12:47:46 -0000 Subject: [GHC] #10756: Allow users to indicate inaccessible patterns In-Reply-To: <044.44fc866587983798150a57353bc7bdbd@haskell.org> References: <044.44fc866587983798150a57353bc7bdbd@haskell.org> Message-ID: <059.ee8d5e946ddb49a6a7f71544948f18c2@haskell.org> #10756: Allow users to indicate inaccessible patterns -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Are you then suggesting that {{{ -- this is OK: impossible :: Int -- this is OK: impossible = 42 -- this is wrong: Just impossible = Just 42 }}} ? This would indeed bind `impossible` and then it would make sense to use the word in expressions. But I find it strange that the pattern `impossible` works at top-level but not elsewhere... it's just another weird wrinkle in a language that already has too many of them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 21 12:51:27 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Aug 2015 12:51:27 -0000 Subject: [GHC] #10785: ghc-pkg appends colon to db path when piped/redirected Message-ID: <045.3d47d5b2ab2694bd10b297d594ba35c3@haskell.org> #10785: ghc-pkg appends colon to db path when piped/redirected -------------------------------------+------------------------------------- Reporter: jgertm | Owner: jgertm Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 7.10.2 Keywords: colon pipe | Operating System: Unknown/Multiple redirect ghc-pkg list | Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Quite simple. Compare the first line of output from {{{#!sh ghc-pkg list ghc-pkg list | head }}} In the second command's output, a colon gets appended at the end of the first line, compared to the first command. This is generally undesired behaviour, since the intent of redirection is to further process the output of the original command. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 21 13:21:37 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Aug 2015 13:21:37 -0000 Subject: [GHC] #10785: ghc-pkg appends colon to db path when piped/redirected In-Reply-To: <045.3d47d5b2ab2694bd10b297d594ba35c3@haskell.org> References: <045.3d47d5b2ab2694bd10b297d594ba35c3@haskell.org> Message-ID: <060.23b329be2ebb0327accbbe1a023c61ca@haskell.org> #10785: ghc-pkg appends colon to db path when piped/redirected -------------------------------------+------------------------------------- Reporter: jgertm | Owner: jgertm Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 7.10.2 Resolution: | Keywords: colon pipe | redirect ghc-pkg list newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * keywords: colon pipe redirect ghc-pkg list => colon pipe redirect ghc- pkg list newcomer Comment: That should be an easy fix for a newcomer. The function to change is `listPackages` in `utils/ghc-pkg/Main.hs`. Also test what happens on a broken package, and notice hidden packages are currently printed differently as well: {{{ $ ghc-pkg list | grep ghc-7.10.2 /opt/ghc/7.10.2/lib/ghc-7.10.2/package.conf.d: (ghc-7.10.2) }}} As a workaround, use: `ghc-pkg list --simple-output`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 21 14:15:03 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Aug 2015 14:15:03 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2310637=3A_Cannot_suppress_=22Warning?= =?utf-8?q?=3A_=7B-=23_SOURCE_=23-=7D_unnecessary_in_import_of__?= =?utf-8?b?4oCYQeKAmSI=?= In-Reply-To: <046.5119908e23481708e117e58b6fa1ab97@haskell.org> References: <046.5119908e23481708e117e58b6fa1ab97@haskell.org> Message-ID: <061.e3bd8cc09e549b1c5b0cf506558f48a4@haskell.org> #10637: Cannot suppress "Warning: {-# SOURCE #-} unnecessary in import of ?A?" ---------------------------------+----------------------------------------- Reporter: phischu | Owner: rpglover64 Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: D1157 ---------------------------------+----------------------------------------- Changes (by rpglover64): * differential: => D1157 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 21 14:24:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Aug 2015 14:24:46 -0000 Subject: [GHC] #1405: Make ghc (stage1) be compilable by non-GHC In-Reply-To: <051.fdfe73ce3bd8dfdeb8a04e3a7bade7ab@haskell.org> References: <051.fdfe73ce3bd8dfdeb8a04e3a7bade7ab@haskell.org> Message-ID: <066.08996ab9a5202976c4b433c6f0c94f11@haskell.org> #1405: Make ghc (stage1) be compilable by non-GHC -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: Type: task | Status: closed Priority: normal | Milestone: ? Component: Compiler | Version: 6.6.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"3452473b4bb180ba327520067b8c6f2a8d6c4f4b/ghc" 3452473b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3452473b4bb180ba327520067b8c6f2a8d6c4f4b" Delete FastBool This reverses some of the work done in Trac #1405, and assumes GHC is smart enough to do its own unboxing of booleans now. I would like to do some more performance measurements, but the code changes can be reviewed already. Test Plan: With a perf build: ./inplace/bin/ghc-stage2 nofib/spectral/simple/Main.hs -fforce-recomp +RTS -t --machine-readable before: ``` [("bytes allocated", "1300744864") ,("num_GCs", "302") ,("average_bytes_used", "8811118") ,("max_bytes_used", "24477464") ,("num_byte_usage_samples", "9") ,("peak_megabytes_allocated", "64") ,("init_cpu_seconds", "0.001") ,("init_wall_seconds", "0.001") ,("mutator_cpu_seconds", "2.833") ,("mutator_wall_seconds", "4.283") ,("GC_cpu_seconds", "0.960") ,("GC_wall_seconds", "0.961") ] ``` after: ``` [("bytes allocated", "1301088064") ,("num_GCs", "310") ,("average_bytes_used", "8820253") ,("max_bytes_used", "24539904") ,("num_byte_usage_samples", "9") ,("peak_megabytes_allocated", "64") ,("init_cpu_seconds", "0.001") ,("init_wall_seconds", "0.001") ,("mutator_cpu_seconds", "2.876") ,("mutator_wall_seconds", "4.474") ,("GC_cpu_seconds", "0.965") ,("GC_wall_seconds", "0.979") ] ``` CPU time seems to be up a bit, but I'm not sure. Unfortunately CPU time measurements are rather noisy. Reviewers: austin, bgamari, rwbarton Subscribers: nomeata Differential Revision: https://phabricator.haskell.org/D1143 GHC Trac Issues: #1405 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 21 14:24:45 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Aug 2015 14:24:45 -0000 Subject: [GHC] #9447: Add support for resizing `MutableByteArray#`s In-Reply-To: <042.51867a8225b599fb4ff13dcceb122580@haskell.org> References: <042.51867a8225b599fb4ff13dcceb122580@haskell.org> Message-ID: <057.ae4d214976ecf5dd76d79879ac155bbf@haskell.org> #9447: Add support for resizing `MutableByteArray#`s -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D133, | Phab:D1139 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"9e8562ae02701270e2c1dfcee3279d862dc5b7b6/ghc" 9e8562a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9e8562ae02701270e2c1dfcee3279d862dc5b7b6" Implement getSizeofMutableByteArrayOp primop Now since ByteArrays are mutable we need to be more explicit about when the size is queried. Test Plan: Add testcase and validate Reviewers: goldfire, hvr, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1139 GHC Trac Issues: #9447 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 21 14:24:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Aug 2015 14:24:46 -0000 Subject: [GHC] #1405: Make ghc (stage1) be compilable by non-GHC In-Reply-To: <051.fdfe73ce3bd8dfdeb8a04e3a7bade7ab@haskell.org> References: <051.fdfe73ce3bd8dfdeb8a04e3a7bade7ab@haskell.org> Message-ID: <066.1036f3394176c9d2115a4c03e3e91c05@haskell.org> #1405: Make ghc (stage1) be compilable by non-GHC -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: Type: task | Status: closed Priority: normal | Milestone: ? Component: Compiler | Version: 6.6.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2f29ebbb6f8c914f2bba624f3edcc259274df8af/ghc" 2f29ebb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2f29ebbb6f8c914f2bba624f3edcc259274df8af" Refactor: delete most of the module FastTypes This reverses some of the work done in #1405, and goes back to the assumption that the bootstrap compiler understands GHC-haskell. In particular: * use MagicHash instead of _ILIT and _CLIT * pattern matching on I# if possible, instead of using iUnbox unnecessarily * use Int#/Char#/Addr# instead of the following type synonyms: - type FastInt = Int# - type FastChar = Char# - type FastPtr a = Addr# * inline the following functions: - iBox = I# - cBox = C# - fastChr = chr# - fastOrd = ord# - eqFastChar = eqChar# - shiftLFastInt = uncheckedIShiftL# - shiftR_FastInt = uncheckedIShiftRL# - shiftRLFastInt = uncheckedIShiftRL# * delete the following unused functions: - minFastInt - maxFastInt - uncheckedIShiftRA# - castFastPtr - panicDocFastInt and pprPanicFastInt * rename panicFastInt back to panic# These functions remain, since they actually do something: * iUnbox * bitAndFastInt * bitOrFastInt Test Plan: validate Reviewers: austin, bgamari Subscribers: rwbarton Differential Revision: https://phabricator.haskell.org/D1141 GHC Trac Issues: #1405 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 21 14:31:36 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Aug 2015 14:31:36 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.3509e876b3447f7055e14f6676b62546@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8226, #8745 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): You're right about the annoyance of a nominal default, and that it's worse than with classes. Bah. And, we may be scared about an efficiency issue that does not arise much in practice, especially with a user-controllable cutoff mechanism. I don't think adding the constructors to interface files helps much, because a client would still need to import the constructors from an exporting module. Simon PJ has had strong opinions here in the past, and I'm curious to see what he thinks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 21 17:23:06 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Aug 2015 17:23:06 -0000 Subject: [GHC] #1851: "make install-strip" should work In-Reply-To: <044.55b2dd35d7abad74f0ebfed90c4f828d@haskell.org> References: <044.55b2dd35d7abad74f0ebfed90c4f828d@haskell.org> Message-ID: <059.cce4d1033c685d884761ba4cba832a0e@haskell.org> #1851: "make install-strip" should work -------------------------------------+------------------------------------- Reporter: igloo | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"47493e60fa2f8f520297969472dde01931530707/ghc" 47493e60/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="47493e60fa2f8f520297969472dde01931530707" Build system: simplify install.mk.in This will allow fixing #1851 more easily ("make install-strip" should work). This reverts 57e2a81c589103b50da80a9e378b1a11285bd521: "On Cygwin, use a Cygwin-style path for /bin/install's destination" Update submodule haddock and hsc2hs. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 21 17:44:03 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Aug 2015 17:44:03 -0000 Subject: [GHC] #10778: GHC doesn't infer all constrains In-Reply-To: <046.c3c6007a301d4e9f2bfd6528e390abd4@haskell.org> References: <046.c3c6007a301d4e9f2bfd6528e390abd4@haskell.org> Message-ID: <061.f7d895ba774c58ba055892c6f71e0fca@haskell.org> #10778: GHC doesn't infer all constrains -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by danilo2): @Simon have a nice holiday! :D -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 21 21:03:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Aug 2015 21:03:01 -0000 Subject: [GHC] #10567: Redundant parser entry point In-Reply-To: <049.8ddc93bc31cd85feb5fe02a4668948de@haskell.org> References: <049.8ddc93bc31cd85feb5fe02a4668948de@haskell.org> Message-ID: <064.3b070ef7df0c2f4a0dd5e1d0f59c4d63@haskell.org> #10567: Redundant parser entry point -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab: | D1014 -------------------------------------+------------------------------------- Changes (by mpickering): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 21 21:03:26 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Aug 2015 21:03:26 -0000 Subject: [GHC] #10558: Alter type of parseDeclaration and parseTypeSignature entry points In-Reply-To: <049.362080c44bcdb3de80ad7a4b94d8a842@haskell.org> References: <049.362080c44bcdb3de80ad7a4b94d8a842@haskell.org> Message-ID: <064.8f8db34ebe06b730d71a044a060d751c@haskell.org> #10558: Alter type of parseDeclaration and parseTypeSignature entry points -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab: | D1007 -------------------------------------+------------------------------------- Changes (by mpickering): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 21 21:11:33 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Aug 2015 21:11:33 -0000 Subject: [GHC] #10785: ghc-pkg appends colon to db path when piped/redirected In-Reply-To: <045.3d47d5b2ab2694bd10b297d594ba35c3@haskell.org> References: <045.3d47d5b2ab2694bd10b297d594ba35c3@haskell.org> Message-ID: <060.b2a0f36c8e6a2a264b72ccbf4c4dec45@haskell.org> #10785: ghc-pkg appends colon to db path when piped/redirected -------------------------------------+------------------------------------- Reporter: jgertm | Owner: jgertm Type: bug | Status: patch Priority: normal | Milestone: Component: ghc-pkg | Version: 7.10.2 Resolution: | Keywords: colon pipe | redirect ghc-pkg list newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1164 -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => patch * differential: => Phab:D1164 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 21 22:01:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Aug 2015 22:01:46 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2310637=3A_Cannot_suppress_=22Warning?= =?utf-8?q?=3A_=7B-=23_SOURCE_=23-=7D_unnecessary_in_import_of__?= =?utf-8?b?4oCYQeKAmSI=?= In-Reply-To: <046.5119908e23481708e117e58b6fa1ab97@haskell.org> References: <046.5119908e23481708e117e58b6fa1ab97@haskell.org> Message-ID: <061.59019855c1a4a202180de0ab0c66399d@haskell.org> #10637: Cannot suppress "Warning: {-# SOURCE #-} unnecessary in import of ?A?" ---------------------------------+----------------------------------------- Reporter: phischu | Owner: rpglover64 Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: D1157 ---------------------------------+----------------------------------------- Comment (by Thomas Miedema ): In [changeset:"a5061a96724922097e4181d452a64618e35fa297/ghc" a5061a9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a5061a96724922097e4181d452a64618e35fa297" Check options before warning about source imports. Summary: Fixes T10637 Reviewers: austin, bgamari, thomie Subscribers: dfordivam, simonpj, thomie Differential Revision: https://phabricator.haskell.org/D1157 GHC Trac Issues: #10637 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 21 22:05:44 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Aug 2015 22:05:44 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2310637=3A_Cannot_suppress_=22Warning?= =?utf-8?q?=3A_=7B-=23_SOURCE_=23-=7D_unnecessary_in_import_of__?= =?utf-8?b?4oCYQeKAmSI=?= In-Reply-To: <046.5119908e23481708e117e58b6fa1ab97@haskell.org> References: <046.5119908e23481708e117e58b6fa1ab97@haskell.org> Message-ID: <061.45475bf14f72dfe16efc382068918379@haskell.org> #10637: Cannot suppress "Warning: {-# SOURCE #-} unnecessary in import of ?A?" -------------------------------------+------------------------------------- Reporter: phischu | Owner: rpglover64 Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | warnings/should_compile/T10637/T10637 Blocked By: | Blocking: Related Tickets: | Differential Revisions: D1157 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * os: Linux => Unknown/Multiple * testcase: => warnings/should_compile/T10637/T10637 * architecture: x86_64 (amd64) => Unknown/Multiple * milestone: => 7.12.1 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 22 01:14:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Aug 2015 01:14:29 -0000 Subject: [GHC] #10775: Enable PolyKinds in GHC.Generics In-Reply-To: <050.1fb49e8a4f9e9ff5b73b6dbae85f944e@haskell.org> References: <050.1fb49e8a4f9e9ff5b73b6dbae85f944e@haskell.org> Message-ID: <065.32bcacd50349e994c413a3b89ae9e900@haskell.org> #10775: Enable PolyKinds in GHC.Generics -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: | RyanGlScott Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1166 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * owner: => RyanGlScott * differential: => Phab:D1166 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 22 07:06:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Aug 2015 07:06:36 -0000 Subject: [GHC] #10786: ghci panic if {-# OPTIONS_GHC -O2 #-} Message-ID: <047.703ab2d30db9b4b24454cf9a6a53aaf3@haskell.org> #10786: ghci panic if {-# OPTIONS_GHC -O2 #-} -----------------------------------------+------------------------------- Reporter: rhovland | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+------------------------------- any file with the pragma OPTIONS_GHC -O2 causes ghci to panic, say something 'impossible' happened, and says to file a bug report. previous ghci ignored this pragma (I think). at any rate, it didn't panic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 22 07:15:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Aug 2015 07:15:45 -0000 Subject: [GHC] #10089: feature: warn about unused data definitions (with typeclass instances) In-Reply-To: <045.113d906ba3b76ec22ad2f715d9c6da96@haskell.org> References: <045.113d906ba3b76ec22ad2f715d9c6da96@haskell.org> Message-ID: <060.acc792b0a126efd380cf0b9ee000e2e2@haskell.org> #10089: feature: warn about unused data definitions (with typeclass instances) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: dfordivam Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by dfordivam): * owner: => dfordivam -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 22 07:35:27 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Aug 2015 07:35:27 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.b142fac66f3772b4bbf16ccb7bcb7853@haskell.org> #7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * status: closed => new * resolution: fixed => Comment: It seems that has resurfaced in 7.10, when compiling uuagc on powerpc: {{{ /tmp/ghcf6f1_0/ghc_153.s: Assembler messages: /tmp/ghcf6f1_0/ghc_153.s:81276:0: Error: operand out of range (0x0000000000008000 is not between 0xffffffffffff8000 and 0x0000000000007fff) /tmp/ghcf6f1_0/ghc_153.s:81278:0: Error: operand out of range (0x0000000000008008 is not between 0xffffffffffff8000 and 0x0000000000007fff) }}} Erik, would you mind having a look? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 22 07:46:15 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Aug 2015 07:46:15 -0000 Subject: [GHC] #10786: ghci panic if {-# OPTIONS_GHC -O2 #-} In-Reply-To: <047.703ab2d30db9b4b24454cf9a6a53aaf3@haskell.org> References: <047.703ab2d30db9b4b24454cf9a6a53aaf3@haskell.org> Message-ID: <062.063da46f40e8bb6aed9f6b640b62c967@haskell.org> #10786: ghci panic if {-# OPTIONS_GHC -O2 #-} -------------------------------------+------------------------------------- Reporter: rhovland | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.10.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #10549 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * os: Linux => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple * related: => #10549 Comment: Sorry to hear you ran into this. This is already fixed in GHC HEAD, see #10549. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 22 09:18:50 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Aug 2015 09:18:50 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.291379da15a0f9d514cfbb0af426e78c@haskell.org> #7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): That's interesting. Git HEAD started displaying this build failure in my Jenkin instance about a week ago but I haven't had a chance to look at it yet. Weird thing is that the Git 7.10 branch build in my Jenkin instance is not failing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 22 14:05:50 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Aug 2015 14:05:50 -0000 Subject: [GHC] #10787: Incorrect code example for pattern synonyms Message-ID: <049.ebf5abc73106dd0931b303481127fab7@haskell.org> #10787: Incorrect code example for pattern synonyms -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.2 Documentation | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- MkT is not the name of a type in the section "Typing of pattern synonyms" https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/syntax- extns.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 22 19:12:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Aug 2015 19:12:14 -0000 Subject: [GHC] #10039: Make Const (Control.Applicative) kind polymorphic in its second argument In-Reply-To: <051.e8daf73d81c353970f587c5857f9575b@haskell.org> References: <051.e8daf73d81c353970f587c5857f9575b@haskell.org> Message-ID: <066.c6ae220a9f8b0648f9212446827a748f@haskell.org> #10039: Make Const (Control.Applicative) kind polymorphic in its second argument -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.4 Resolution: | Keywords: report- | impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 22 21:48:11 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Aug 2015 21:48:11 -0000 Subject: [GHC] #10756: Allow users to indicate inaccessible patterns In-Reply-To: <044.44fc866587983798150a57353bc7bdbd@haskell.org> References: <044.44fc866587983798150a57353bc7bdbd@haskell.org> Message-ID: <059.e12ec3b1a2be4681c0a809d2897315ea@haskell.org> #10756: Allow users to indicate inaccessible patterns -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by YitzGale): Replying to [comment:9 goldfire]: Correct. The first two would be valid and retain their current meaning. The third is invalid for two reasons: because `Just` requires an argument, and because the bound RHS value is omitted after an impossible pattern. I'm not sure what you mean by "top level". My proposal is similar to many other features of Haskell as well as almost every other language - that certain tokens are given special meaning in specific syntactic contexts. Why is that a weird wrinkle? A few existing examples: `as` and `qualified` have special meaning only in `import` statements; `forall` and `.` only have special meaning in type expresssions; etc. In general, it's a good idea to keep keywords to a minimum; otherwise the language becomes increasingly awkward to use. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 23 09:38:46 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Aug 2015 09:38:46 -0000 Subject: [GHC] #10762: On Windows, out-of-codepage characters can cause GHC build to fail In-Reply-To: <047.594293f39928454a6845b64e2efaf718@haskell.org> References: <047.594293f39928454a6845b64e2efaf718@haskell.org> Message-ID: <062.ec76a919af9de81bb4670162f7122766@haskell.org> #10762: On Windows, out-of-codepage characters can cause GHC build to fail ---------------------------------+----------------------------------------- Reporter: snoyberg | Owner: snoyberg Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6037 | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by snoyberg): I've sent one final diff for this issue, implementing the environment override logic I mentioned here: https://phabricator.haskell.org/D1167 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 23 17:54:13 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Aug 2015 17:54:13 -0000 Subject: [GHC] #10788: performance regression involving minimum (and maybe Vector) Message-ID: <047.bfa4fa3fe86eacf6fba28b5097b23381@haskell.org> #10788: performance regression involving minimum (and maybe Vector) -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- This program (taken from http://stackoverflow.com/questions/32158319 /difference-in-performance-for-coin-change-between-haskell-and-c) runs about 50% slower when compiled with `ghc-7.10.1 -O` compared to `ghc-7.8.4 -O`. {{{ import Data.Vector.Unboxed as U ((!), constructN, length) coinchangev :: Int -> [Int] -> Int coinchangev n cs = v ! n where v = constructN (n+1) f f w = case U.length w of 0 -> 0 m -> 1 + minimum [w ! x | x <- map (m-) cs, x >= 0] main = print $ coinchangev 10000000 [1, 5, 10, 25, 100] }}} However if I change `minimum` to `sum`, while the runtime in 7.8.4 is unchanged, the runtime in 7.10.1 drops by a factor of 5! Allocations also decrease by a large factor. So my guess is that something has gone wrong with call arity analysis for `minimum` (and gone very right for `sum`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 23 19:08:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Aug 2015 19:08:44 -0000 Subject: [GHC] #10788: performance regression involving minimum (and maybe Vector) In-Reply-To: <047.bfa4fa3fe86eacf6fba28b5097b23381@haskell.org> References: <047.bfa4fa3fe86eacf6fba28b5097b23381@haskell.org> Message-ID: <062.476d1c3c125aef1eb21419e8d1e3b619@haskell.org> #10788: performance regression involving minimum (and maybe Vector) -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): In 7.8, both `minimum` and `sum` were non-fusing left-folds. In 7.10, `sum`, via `foldl`, is fusing, so this is the 5? improvement you observe. `minimum` is not easily foldable: It is a `foldl1`, which treats the first `(:)` different from the rest, and it is not clear how to fix that. So performance difference between `minimum` and `sum` in 7.10 can be explained. What needs to be investigated is why 7.10 degraded by 50% over 7.8. I do not expect Call Arity/foldl fusion to play a role here, but I might be wrong. BTW: One could reasonably expect the compiler to transform `minimum (x:xs)` into `foldl' min x xs`, which could then maybe fuse, but that does not seem to be the case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 23 19:28:55 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Aug 2015 19:28:55 -0000 Subject: [GHC] #10788: performance regression involving minimum (and maybe Vector) In-Reply-To: <047.bfa4fa3fe86eacf6fba28b5097b23381@haskell.org> References: <047.bfa4fa3fe86eacf6fba28b5097b23381@haskell.org> Message-ID: <062.216b61ff2340391449daaf5a92a1b050@haskell.org> #10788: performance regression involving minimum (and maybe Vector) -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): GHC 7.8 will actually inline `minimum` (and hence `foldl1` and `foldl`), allowing the compiler to specialize it for the type at hand: {{{#!hs Rec { $wlgo_r6X4 :: GHC.Prim.Int# -> [GHC.Types.Int] -> GHC.Prim.Int# [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType ] $wlgo_r6X4 = \ (ww_s6TV :: GHC.Prim.Int#) (w_s6TS :: [GHC.Types.Int]) -> case w_s6TS of _ [Occ=Dead] { [] -> ww_s6TV; : x_a52E xs_a52F -> case x_a52E of _ [Occ=Dead] { GHC.Types.I# y1_a52Q -> case GHC.Prim.tagToEnum# @ GHC.Types.Bool (GHC.Prim.<=# ww_s6TV y1_a52Q) of _ [Occ=Dead] { GHC.Types.False -> $wlgo_r6X4 y1_a52Q xs_a52F; GHC.Types.True -> $wlgo_r6X4 ww_s6TV xs_a52F } } } end Rec } }}} GHC-7.10 will ''not'' inline `minimum`, but only replace it by `minimumStrict` via a rule, and the latter then called polymorphically: {{{#!hs ... case strictMinimum @ Int GHC.Classes.$fOrdInt (go_a6gJ cs_r9bl) of _ [Occ=Dead] { I# y_a6hm -> }}} GHC-7.8?s inlining seems to be a little excessive, but in 7.10 there is certainly a lack of specialization. Maybe some `INLINEABLE` pragma would help? Not sure... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 23 20:05:03 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Aug 2015 20:05:03 -0000 Subject: [GHC] #10788: performance regression involving minimum (and maybe Vector) In-Reply-To: <047.bfa4fa3fe86eacf6fba28b5097b23381@haskell.org> References: <047.bfa4fa3fe86eacf6fba28b5097b23381@haskell.org> Message-ID: <062.07875f15cf4c1deb342c1d87b8e94948@haskell.org> #10788: performance regression involving minimum (and maybe Vector) -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): It looks like more inlining happened in 7.10.1 at the definition site of `strictMinimum`, and the result was that the unfolding became too large for GHC to want to inline it at use sites. 7.8.4: {{{ Considering inlining: Data.List.strictMinimum arg infos [ValueArg, NonTrivArg] uf arity 2 interesting continuation CaseCtxt some_benefit True is exp: True is work-free: True guidance IF_ARGS [30 30] 80 0 discounted size = -10 ANSWER = YES strictMinimum :: GHC.Classes.Ord a -> [a] -> a {- Arity: 2, Strictness: , Unfolding: (\ @ a $dOrd :: GHC.Classes.Ord a ds :: [a] -> case ds of wild { [] -> Data.List.minimum1 @ a : ipv ipv1 -> Data.List.foldl' @ a @ a (GHC.Classes.min @ a $dOrd) ipv ipv1 }) -} }}} 7.10.1: {{{ Considering inlining: strictMinimum arg infos [ValueArg, NonTrivArg] interesting continuation CaseCtxt some_benefit True is exp: True is work-free: True guidance IF_ARGS [30 30] 200 0 discounted size = 110 ANSWER = NO strictMinimum :: Ord a => [a] -> a {- Arity: 2, Strictness: , Unfolding: (\ @ a $dOrd :: Ord a ds :: [a] -> case ds of wild { [] -> minimum1 @ a : ipv ipv1 -> let { k :: a -> a -> a = min @ a $dOrd } in letrec { go :: [a] -> a -> a {- Arity: 2, Strictness: -} = \ ds1 :: [a] eta :: a -> case ds1 of wild1 { [] -> eta : y ys -> case eta of z { DEFAULT -> go ys (k z y) } } } in go ipv1 ipv }) -} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 23 20:09:09 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Aug 2015 20:09:09 -0000 Subject: [GHC] #10788: performance regression involving minimum (was: performance regression involving minimum (and maybe Vector)) In-Reply-To: <047.bfa4fa3fe86eacf6fba28b5097b23381@haskell.org> References: <047.bfa4fa3fe86eacf6fba28b5097b23381@haskell.org> Message-ID: <062.be30369938a5eb306e35d84327c2aa6d@haskell.org> #10788: performance regression involving minimum -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * owner: => ekmett * component: Compiler => Core Libraries -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 23 20:23:05 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Aug 2015 20:23:05 -0000 Subject: [GHC] #10788: performance regression involving minimum In-Reply-To: <047.bfa4fa3fe86eacf6fba28b5097b23381@haskell.org> References: <047.bfa4fa3fe86eacf6fba28b5097b23381@haskell.org> Message-ID: <062.50f45b483c4e79ff83a6e22b1bc7635f@haskell.org> #10788: performance regression involving minimum -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): So one solution would be to mark `strictMinimum` as `INLINE`, so that its unfolding stays small and both `strictMinimum` and `foldl` will be inlined at the use site? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 02:48:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 02:48:02 -0000 Subject: [GHC] #1830: Automatic derivation of Lift In-Reply-To: <044.3eb409743bc4021eb94e63cb46f573bc@haskell.org> References: <044.3eb409743bc4021eb94e63cb46f573bc@haskell.org> Message-ID: <059.cb36760cfc83df650ab1f0dbe6ed8563@haskell.org> #1830: Automatic derivation of Lift -------------------------------------+------------------------------------- Reporter: guest | Owner: | RyanGlScott Type: feature request | Status: new Priority: normal | Milestone: ? Component: Template Haskell | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1168 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * owner: => RyanGlScott * differential: => Phab:D1168 Comment: I have a differential ( Phab:D1168 ) submitted which implements this feature, but I would like some feedback. I'll copy over my questions from the Phabricator page: 1. What should we do if someone attempts to derive `Lift` on a datatype with no constructors? I (somewhat arbitrarily) chose it to generate code like this: {{{#!hs data Void deriving Lift instance Lift Void where lift _ = appE (varE 'error) (litE (stringL "Void lift")) }}} but {{{lift _ = error "Void lift"}}} would also work. 2. How should primitive data types be handled? I adapted the approach `Show` takes, which has special cases for `Char#`, `Float#`, `Double#`, `Int#`, and `Word#`. Note that `template-haskell` also has a `StringPrimL` constructor, so we could handle `Addr#` as well, but there's not currently a function of type `String -> [Word8]` in `base` that I could use in conjunction with it ([http://haddock.stackage.org/lts-3.2/ghc-7.10.2/SMRep.html#v:stringToWord8s there is in] `ghc`, but I'm not sure if it's verboten to put GHC internals in derived code). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 04:07:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 04:07:37 -0000 Subject: [GHC] #1830: Automatic derivation of Lift In-Reply-To: <044.3eb409743bc4021eb94e63cb46f573bc@haskell.org> References: <044.3eb409743bc4021eb94e63cb46f573bc@haskell.org> Message-ID: <059.8d6f4ab88afa93c91cab495963881713@haskell.org> #1830: Automatic derivation of Lift -------------------------------------+------------------------------------- Reporter: guest | Owner: | RyanGlScott Type: feature request | Status: new Priority: normal | Milestone: ? Component: Template Haskell | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1168 -------------------------------------+------------------------------------- Comment (by rwbarton): > What should we do if someone attempts to derive `Lift` on a datatype with no constructors? Since `lift` then has type `Void -> Q Exp`, I would be inclined to define it as `absurd`, i.e., an empty case. I don't see the point of turning it into a runtime error when `lift (error "foo")` is a splice-time error for an inhabited type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 04:47:01 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 04:47:01 -0000 Subject: [GHC] #10682: AArch64: dll-split: out of memory (requested 1099512676352 bytes) In-Reply-To: <044.b28ef9f55aa85f3be9d617cd7c0f70a5@haskell.org> References: <044.b28ef9f55aa85f3be9d617cd7c0f70a5@haskell.org> Message-ID: <059.d29792f7e5e9b7f065b56c0fca8d009f@haskell.org> #10682: AArch64: dll-split: out of memory (requested 1099512676352 bytes) ----------------------------------------+---------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Comment (by erikd): I added debug to `rts/posix/OSMem.c` to print out the values that were being passed to `mmap`. I then wrote a simple standalone program to see of `mmap` still failed with the same parameters outside of GHC. The program is: {{{ #include #include #include int main (void) { void *addr = (void*) 0x200000000, *ret ; size_t size = 1099512676352 ; int prot = 0, flags = MAP_NORESERVE | MAP_ANON | MAP_PRIVATE ; ret = mmap(addr, size, prot, flags, -1, 0); if (ret == NULL) { perror ("mmap") ; exit (1) ; } puts ("Success!") ; return 0 ; } }}} and it compiled and ran successfully on the same machine where GHC is currently failing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 07:27:11 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 07:27:11 -0000 Subject: [GHC] #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` In-Reply-To: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> References: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> Message-ID: <057.9d9cad04d28f03428a96d810aad47b72@haskell.org> #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Core Libraries | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | simplCore/should_compile/T8832 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * cc: ekmett (added) * owner: => ekmett * component: Compiler => Core Libraries Comment: OK so this is a library problem, not a GHC problem. Core Libraries Committee, might you take this on? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 07:53:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 07:53:02 -0000 Subject: [GHC] #10600: -fwarn-incomplete-patterns doesn't work with -fno-code In-Reply-To: <043.972d3170891da80a4e96bca7b675a836@haskell.org> References: <043.972d3170891da80a4e96bca7b675a836@haskell.org> Message-ID: <058.d0a7560af2cfae466ef25bd83f742398@haskell.org> #10600: -fwarn-incomplete-patterns doesn't work with -fno-code -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | driver/T8101b Blocked By: | Blocking: Related Tickets: #8101 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): This can't be hard to fix... would anyone like to look at it? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 08:08:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 08:08:15 -0000 Subject: [GHC] #8347: Add a Strict LANGUAGE pragma In-Reply-To: <044.d01bb368b2606104539d1aa05530b018@haskell.org> References: <044.d01bb368b2606104539d1aa05530b018@haskell.org> Message-ID: <059.cf0c91067c57715a4c0d72d4929a2f21@haskell.org> #8347: Add a Strict LANGUAGE pragma -------------------------------------+------------------------------------- Reporter: tibbe | Owner: adamse Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: | Phab:D1033, Phab:D1142 -------------------------------------+------------------------------------- Changes (by simonpj): * cc: adamse, tibbe (added) Comment: If this is committed, can we close it? However, I wish there were a few regression tests to demonstrate the feature. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 09:04:51 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 09:04:51 -0000 Subject: [GHC] #4243: Make a proper options parser for the RTS In-Reply-To: <044.6ea5654174cc0120653bc110fe1a703c@haskell.org> References: <044.6ea5654174cc0120653bc110fe1a703c@haskell.org> Message-ID: <059.c79c965a2dd5cec8ac67dedfe371f297@haskell.org> #4243: Make a proper options parser for the RTS -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 7535 Related Tickets: #9839 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): osa1, I think for the sake of simplicity it would be best to avoid going down that road. The RTS really just needs to work, even if Haskell-land is broken (e.g. as is often the case when debugging RTS bugs or bringing up new platforms). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 10:56:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 10:56:04 -0000 Subject: [GHC] #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` In-Reply-To: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> References: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> Message-ID: <057.063aff5f88b271481a607238c3ea5b6d@haskell.org> #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Core Libraries | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | simplCore/should_compile/T8832 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): For the record, hvr has indicated that he will eventually be implementing a more efficient `bitInteger`. However, this still means that `Integer` won't get proper constant folding (as it won't be implemented in terms of `shiftL`). I'm not really sure it's fair to call this a library problem: the compiler currently makes the library author choose between having a constant-folded `bit` implementation (by implementing in terms of other operations which are constant folded) or an implementation which is implemented efficiently for the type in question. There are a few ways we could handle this: 1. add a `PrelRule` to specifically handle `Bits.bits` 2. somehow extend the rule rewriting system to allow these rules to be expressed in the source language Option 1 is unfortunate in that `Bits.bits` is likely far from the last operation which will need this treatment. Moreover, it leaves users who want to implement other types implementing `Bits` and similar classes covered by `PrelRules` high and dry. Arguably this is a limitation of the rule rewriting system, hence option 2. At first glance it would seem like allowing a rule to match conditioned on the nature of its arguments (either literal or non-literal) and allowing compile-time evaluation of the RHS may be sufficient to address this. This, however, would be non-trivial to implement (namely compile- time evaluation would require the interpreter) and may present termination issues. For these reasons (and perhaps others I haven't yet thought of) I doubt this is a viable path. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 11:06:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 11:06:49 -0000 Subject: [GHC] #8347: Add a Strict LANGUAGE pragma In-Reply-To: <044.d01bb368b2606104539d1aa05530b018@haskell.org> References: <044.d01bb368b2606104539d1aa05530b018@haskell.org> Message-ID: <059.ef17e621a5c10d80927ba5e0ebf7c776@haskell.org> #8347: Add a Strict LANGUAGE pragma -------------------------------------+------------------------------------- Reporter: tibbe | Owner: adamse Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: | Phab:D1033, Phab:D1142 -------------------------------------+------------------------------------- Comment (by tibbe): Only the `StrictData` part is done. The more general `Strict` pragma (i.e. also dealing with bindings) is still waiting for review (https://phabricator.haskell.org/D1142). If you haven't taken a look already, please do so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 12:14:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 12:14:25 -0000 Subject: [GHC] #10789: Notify user when a kind mismatch holds up a type family reduction Message-ID: <047.282dd8bb976bc76373d556a5e980ac6e@haskell.org> #10789: Notify user when a kind mismatch holds up a type family reduction -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Consider this contrived example: {{{ {-# LANGUAGE TypeFamilies, PolyKinds, UndecidableInstances #-} module Bug where import Data.Proxy type family F (a :: k) :: k type instance F a = G a type family G a type instance G a = a foo :: Proxy (F Maybe) -> Proxy Maybe foo = id }}} This (correctly) fails to compile. The error message is {{{ Bug.hs:14:7: Couldn't match type ?F Maybe? with ?Maybe? Expected type: Proxy (F Maybe) -> Proxy Maybe Actual type: Proxy Maybe -> Proxy Maybe In the expression: id In an equation for ?foo?: foo = id Failed, modules loaded: none. }}} But this is peculiar, but it surely looks like `F` should be a type-level identity function! Of course, upon further inspection, we see that `F` is partial. It reduces only at kind `*`. This is quite hard to figure out, though, especially given that we're using the "default to `*`" behavior of open type families to arrange for this kind restriction. Thus, I propose: figure out when a type family reduction is held up due to a kind mismatch, and inform the user. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 12:18:59 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 12:18:59 -0000 Subject: [GHC] #10789: Notify user when a kind mismatch holds up a type family reduction In-Reply-To: <047.282dd8bb976bc76373d556a5e980ac6e@haskell.org> References: <047.282dd8bb976bc76373d556a5e980ac6e@haskell.org> Message-ID: <062.bb5980e185a4533025f7ef3befa19959@haskell.org> #10789: Notify user when a kind mismatch holds up a type family reduction -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): See also #10775 for the error that originally inspired this request. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 12:35:44 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 12:35:44 -0000 Subject: [GHC] #10782: Existential variables not scoped? In-Reply-To: <047.163aa6e21fe23b588fdda5e44a010081@haskell.org> References: <047.163aa6e21fe23b588fdda5e44a010081@haskell.org> Message-ID: <062.c2acce2505bc706945c697879d5d354e@haskell.org> #10782: Existential variables not scoped? -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Can you give an example of some kind? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 12:52:13 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 12:52:13 -0000 Subject: [GHC] #10756: Allow users to indicate inaccessible patterns In-Reply-To: <044.44fc866587983798150a57353bc7bdbd@haskell.org> References: <044.44fc866587983798150a57353bc7bdbd@haskell.org> Message-ID: <059.29bedfcc839973574acf357613410f67@haskell.org> #10756: Allow users to indicate inaccessible patterns -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): The syntactic construct that assigns values to variables looks like ''pattern'' = ''expression'' What you are proposing is that this becomes ''top_level_pattern'' = ''expression'' where ''top_level_pattern'' is just like ''pattern'', but also admits the word `impossible`. That is, the thing to the left of an `=` is ''always'' a pattern in Haskell, even if it's a trivially simple one like a bare identifier. But I see another way forward here. The problem is that something like `foo = bar` can be seen in two different lights: `foo` can be a trivial pattern, or `foo` can be a 0-argument function. Seen as the former, we have the annoying ''top_level_pattern'' stuff above. Seen as the latter, this makes more sense. So your proposal would also allow {{{ impossible x = x + 1 }}} In that declaration, `impossible` clearly is not in a pattern position, so it's OK. Changing the treatment of `foo = bar` from a pattern binding to a function binding would also fix <>. I think I'm coming around to your point of view here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 13:09:28 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 13:09:28 -0000 Subject: [GHC] #1830: Automatic derivation of Lift In-Reply-To: <044.3eb409743bc4021eb94e63cb46f573bc@haskell.org> References: <044.3eb409743bc4021eb94e63cb46f573bc@haskell.org> Message-ID: <059.2d2d88c29520571c90709f76a25108d3@haskell.org> #1830: Automatic derivation of Lift -------------------------------------+------------------------------------- Reporter: guest | Owner: | RyanGlScott Type: feature request | Status: new Priority: normal | Milestone: ? Component: Template Haskell | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1168 -------------------------------------+------------------------------------- Comment (by goldfire): Thanks for taking this on, Ryan, but I'm unconvinced that GHC needs built- in support here. What's wrong with using `th-lift`? I mean, I agree that in theory, `DeriveLift` would be nice, but it's Yet Another Thing. If something can be done well outside of GHC, I think it should be. A common argument here is that if a feature is built-in (as opposed to requiring TH), then users don't have to use TH. But that argument falls flat here, because users are clearly already using TH! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 13:45:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 13:45:48 -0000 Subject: [GHC] #9517: hp2ps generates invalid postscript file In-Reply-To: <045.a830b70a270e850cd0392ed106ef100c@haskell.org> References: <045.a830b70a270e850cd0392ed106ef100c@haskell.org> Message-ID: <060.83b460c456acdd2d8b569e5128d40ec8@haskell.org> #9517: hp2ps generates invalid postscript file -------------------------------------+------------------------------------- Reporter: JamesM | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by zardoz): * version: 7.8.3 => 7.10.2 * os: MacOS X => Unknown/Multiple * architecture: x86 => Unknown/Multiple Comment: I?m also encountering this all the time on Linux, GHC 7.10.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 14:37:19 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 14:37:19 -0000 Subject: [GHC] #10682: AArch64: dll-split: out of memory (requested 1099512676352 bytes) In-Reply-To: <044.b28ef9f55aa85f3be9d617cd7c0f70a5@haskell.org> References: <044.b28ef9f55aa85f3be9d617cd7c0f70a5@haskell.org> Message-ID: <059.d56d7738b5b65724373c51baab7a8ad1@haskell.org> #10682: AArch64: dll-split: out of memory (requested 1099512676352 bytes) ----------------------------------------+---------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Changes (by kgardas): * cc: kgardas (added) Comment: Replying to [ticket:10682 erikd]: > Some time in the last week, GHC Git HEAD started to fail to build with: > > {{{ > dll-split: out of memory (requested 1099512676352 bytes) > compiler/ghc.mk:655: recipe for target 'compiler/stage2/dll-split.stamp' failed > }}} > > Obviously, attempting to allocate a terrabyte is not going to work. > > Will try to git bisect. This is very similar to what I get here on amd64/solaris11 builder[1] after I've been able to start it after holidays. Perhaps the same issue? I'll try to debug that too as time permits. [1]: http://haskell.inf.elte.hu/builders/solaris-amd64-head/index.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 16:03:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 16:03:17 -0000 Subject: [GHC] #8347: Add a Strict LANGUAGE pragma In-Reply-To: <044.d01bb368b2606104539d1aa05530b018@haskell.org> References: <044.d01bb368b2606104539d1aa05530b018@haskell.org> Message-ID: <059.7be417c7b29950fad92142c708b1695b@haskell.org> #8347: Add a Strict LANGUAGE pragma -------------------------------------+------------------------------------- Reporter: tibbe | Owner: adamse Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: | Phab:D1033, Phab:D1142 -------------------------------------+------------------------------------- Comment (by simonpj): OK I'll do that. Still, regression tests for the `StrictData` part would be good. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 16:17:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 16:17:22 -0000 Subject: [GHC] #8347: Add a Strict LANGUAGE pragma In-Reply-To: <044.d01bb368b2606104539d1aa05530b018@haskell.org> References: <044.d01bb368b2606104539d1aa05530b018@haskell.org> Message-ID: <059.2d43c2dcd29953fb192867533cc5efc7@haskell.org> #8347: Add a Strict LANGUAGE pragma -------------------------------------+------------------------------------- Reporter: tibbe | Owner: adamse Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: | Phab:D1033, Phab:D1142 -------------------------------------+------------------------------------- Comment (by adamse): See https://ghc.haskell.org/trac/ghc/browser/ghc/testsuite/tests/deSugar/should_run/DsStrictData.hs?rev=a5061a96724922097e4181d452a64618e35fa297 for regression tests for `StrictData`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 16:17:51 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 16:17:51 -0000 Subject: [GHC] #8347: Add a Strict LANGUAGE pragma In-Reply-To: <044.d01bb368b2606104539d1aa05530b018@haskell.org> References: <044.d01bb368b2606104539d1aa05530b018@haskell.org> Message-ID: <059.358b597ac1e818cf1a3b7e957cfa1c02@haskell.org> #8347: Add a Strict LANGUAGE pragma -------------------------------------+------------------------------------- Reporter: tibbe | Owner: adamse Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | DsStrictData Blocked By: | Blocking: Related Tickets: | Differential Revisions: | Phab:D1033, Phab:D1142 -------------------------------------+------------------------------------- Changes (by adamse): * testcase: => DsStrictData -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 16:20:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 16:20:04 -0000 Subject: [GHC] #10756: Allow users to indicate inaccessible patterns In-Reply-To: <044.44fc866587983798150a57353bc7bdbd@haskell.org> References: <044.44fc866587983798150a57353bc7bdbd@haskell.org> Message-ID: <059.1d18a79156fda515f268c01b0f464767@haskell.org> #10756: Allow users to indicate inaccessible patterns -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by YitzGale): Replying to [comment:11 goldfire]: I agree. I anyway wasn't thinking of turning everything into a pattern binding. Other than type aliases and record syntax, the LHS of = is either a function binding or a pattern binding, both of which include a pattern expression. In both cases `impossible` following the pattern expression makes sense, provided that the pattern expression is non-empty. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 16:36:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 16:36:06 -0000 Subject: [GHC] #8347: Add a Strict LANGUAGE pragma In-Reply-To: <044.d01bb368b2606104539d1aa05530b018@haskell.org> References: <044.d01bb368b2606104539d1aa05530b018@haskell.org> Message-ID: <059.dd3edc6e1aba2a1c1367f9163e9efaa0@haskell.org> #8347: Add a Strict LANGUAGE pragma -------------------------------------+------------------------------------- Reporter: tibbe | Owner: adamse Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | DsStrictData Blocked By: | Blocking: Related Tickets: | Differential Revisions: | Phab:D1033, Phab:D1142 -------------------------------------+------------------------------------- Comment (by simonpj): Sorry, missed that test. Good! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 16:37:59 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 16:37:59 -0000 Subject: [GHC] #1830: Automatic derivation of Lift In-Reply-To: <044.3eb409743bc4021eb94e63cb46f573bc@haskell.org> References: <044.3eb409743bc4021eb94e63cb46f573bc@haskell.org> Message-ID: <059.b8044044e89e7358e06e3ddd0ec7b608@haskell.org> #1830: Automatic derivation of Lift -------------------------------------+------------------------------------- Reporter: guest | Owner: | RyanGlScott Type: feature request | Status: new Priority: normal | Milestone: ? Component: Template Haskell | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1168 -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:10 goldfire]: > What's wrong with using `th-lift`? Type inference. `th-lift` is fundamentally limited in that it cannot infer the correct instance context for complex data structures such as {{{#!hs data Nested f a = Nested (f a) deriving Lift -- instance Lift (f a) => Lift (Nested f a) where ... }}} or {{{#!hs data R a = R a instance (Show a, Lift a) => Lift (R a) where ... data Restricted a = Restricted (R a) deriving Lift -- instance (Show a, Lift a) => Lift (Restricted a) where ... }}} Granted, this could be improved if `th-lift` were changed to allow something like this: {{{#!hs instance (Show a, Lift a) => Lift (Restricted a) where lift = $(makeLift ''Restricted) }}} But a `deriving` statement is infinitely more aesthetically pleasing, in my opinion. > But that argument falls flat here, because users are clearly already using TH! Well, they're using the `template-haskell` library, but not necessarily the `TemplateHaskell` extension. Users may want to define `Lift` instances for data types without actually using the `TemplateHaskell` extension (as doing so precludes a library from being built on a stage-1 compiler). Having access to `DeriveLift` allows a library to be built with `Lift` support on GHC stage 1 and 2, and then downstream packages that depend on the library can decide if they want to actually utilize the `Lift` instances by means of the `TemplateHaskell` extension. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 16:38:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 16:38:15 -0000 Subject: [GHC] #10756: Allow users to indicate inaccessible patterns In-Reply-To: <044.44fc866587983798150a57353bc7bdbd@haskell.org> References: <044.44fc866587983798150a57353bc7bdbd@haskell.org> Message-ID: <059.c2182f80ce20bfb18f4250dbc953fd12@haskell.org> #10756: Allow users to indicate inaccessible patterns -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): A binding `foo = bar` is already regarded as a function binding in GHC. From `HsBinds`: {{{ = -- | FunBind is used for both functions @f x = e@ -- and variables @f = \x -> e@ -- -- Reason 1: Special case for type inference: see 'TcBinds.tcMonoBinds'. -- -- Reason 2: Instance decls can only have FunBinds, which is convenient. -- If you change this, you'll need to change e.g. rnMethodBinds -- -- But note that the form @f :: a->a = ...@ -- parses as a pattern binding, just like -- @(f :: a -> a) = ... @ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 16:41:41 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 16:41:41 -0000 Subject: [GHC] #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` In-Reply-To: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> References: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> Message-ID: <057.acb4041d66f88aa5e91b20e92bb1309c@haskell.org> #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Core Libraries | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | simplCore/should_compile/T8832 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): Simon, I can talk to Herbert about fixing up `bitBigNat#`, but if the issue is that having it at all kills constant folding, it sounds like we'd still have a problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 17:00:11 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 17:00:11 -0000 Subject: [GHC] #3379: GHC should use the standard binary package In-Reply-To: <044.fa4dfe8be6394c3f94f6b68d8a40f5e7@haskell.org> References: <044.fa4dfe8be6394c3f94f6b68d8a40f5e7@haskell.org> Message-ID: <059.c613fddf2a97ab7b31a8bc6a55d00008@haskell.org> #3379: GHC should use the standard binary package -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * cc: kolmodin, jstolarek (added) Comment: The binary package received a portable implementation of `instance Binary Integer` in the following commit: https://github.com/kolmodin/binary/commit/2109b28f4d3919dbedcf42c97e51471165278a5c GHC's version looks like this: {{{ instance Binary Integer where -- XXX This is hideous put_ bh i = put_ bh (show i) get bh = do str <- get bh case reads str of [(i, "")] -> return i _ -> fail ("Binary Integer: got " ++ show str) }}} As mentioned in Phab:D1165, `compiler/utils/Binary.hs` contains also a commented out implementation of `instance Binary Integer`. It is supposedly more efficient than the one in the `binary` package (but not portable?). This should all be cleared and cleaned up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 17:05:54 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 17:05:54 -0000 Subject: [GHC] #8330: Remove ExtsCompat46 module once we bootstrap with GHC 7.8 In-Reply-To: <048.595f7c7e08c33e6ee323b64468923777@haskell.org> References: <048.595f7c7e08c33e6ee323b64468923777@haskell.org> Message-ID: <063.59c3fbcfef5193fc7c7597f9102a4fa9@haskell.org> #8330: Remove ExtsCompat46 module once we bootstrap with GHC 7.8 -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: highest | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"37a0b50b5e28a326159bb464effb499c1d9de775/ghc" 37a0b50/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="37a0b50b5e28a326159bb464effb499c1d9de775" Delete ExtsCompat46 (#8330) We require ghc-7.8 to build HEAD (ghc-7.11). Differential Revision: https://phabricator.haskell.org/D1165 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 17:08:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 17:08:23 -0000 Subject: [GHC] #8330: Remove ExtsCompat46 module once we bootstrap with GHC 7.8 In-Reply-To: <048.595f7c7e08c33e6ee323b64468923777@haskell.org> References: <048.595f7c7e08c33e6ee323b64468923777@haskell.org> Message-ID: <063.0b90b621f8d2b4f837557b26d58254e5@haskell.org> #8330: Remove ExtsCompat46 module once we bootstrap with GHC 7.8 -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: closed Priority: highest | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: Done! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 18:35:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 18:35:24 -0000 Subject: [GHC] #10682: AArch64: dll-split: out of memory (requested 1099512676352 bytes) In-Reply-To: <044.b28ef9f55aa85f3be9d617cd7c0f70a5@haskell.org> References: <044.b28ef9f55aa85f3be9d617cd7c0f70a5@haskell.org> Message-ID: <059.af551e27ec8f9927496e0bbb6163751e@haskell.org> #10682: AArch64: dll-split: out of memory (requested 1099512676352 bytes) ----------------------------------------+---------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Comment (by ezyang): First off, even if the symptoms are the same, I would recommend opening a separate bug for 64-bit Solaris 11 not working, because the underlying cause/fix are very unlikely to be the same. According to some source comments in the Go project (https://golang.org/src/runtime/malloc.go#L158 and https://golang.org/src/runtime/malloc.go#L260), there are restrictions on how much virtual memory you can actually get on ARM64; in particular, apparently only 39 bits of user address space is allowed (which is about 500 GB). So it seems likely that if we halve the requested address size we might do better. However, in that case, I don't understand why the mini test-program is working. Do you have the ability to strace executables on ARM64, to find out what the sequence of mmap calls are? I don't think Giovanni or I have access to ARM64 machines which will make it a little harder for us to debug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 19:08:54 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 19:08:54 -0000 Subject: [GHC] #1830: Automatic derivation of Lift In-Reply-To: <044.3eb409743bc4021eb94e63cb46f573bc@haskell.org> References: <044.3eb409743bc4021eb94e63cb46f573bc@haskell.org> Message-ID: <059.24f32c20a1ffbc85e295ce5fe8826121@haskell.org> #1830: Automatic derivation of Lift -------------------------------------+------------------------------------- Reporter: guest | Owner: | RyanGlScott Type: feature request | Status: new Priority: normal | Milestone: ? Component: Template Haskell | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1168 -------------------------------------+------------------------------------- Comment (by mpickering): Is it possible to derive these instances using GHC.Generics? Then the DeriveAnyClass extension could be used for the same syntactic effect without modifying the compiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 19:14:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 19:14:58 -0000 Subject: [GHC] #1830: Automatic derivation of Lift In-Reply-To: <044.3eb409743bc4021eb94e63cb46f573bc@haskell.org> References: <044.3eb409743bc4021eb94e63cb46f573bc@haskell.org> Message-ID: <059.7900d42cc6e762ee5133dd64a9f388cc@haskell.org> #1830: Automatic derivation of Lift -------------------------------------+------------------------------------- Reporter: guest | Owner: | RyanGlScott Type: feature request | Status: new Priority: normal | Milestone: ? Component: Template Haskell | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1168 -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:12 mpickering]: > Is it possible to derive these instances using GHC.Generics? I believe so, although with `GHC.Generics` you cannot have special cases for unlifted types like `Int#` (currently, the Phab differential uses the [http://hackage.haskell.org/package/template-haskell-2.10.0.0/docs /Language-Haskell-TH-Syntax.html#t:Lit Lit] type from `template-haskell` to deal with them). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 19:16:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 19:16:20 -0000 Subject: [GHC] #10682: AArch64: dll-split: out of memory (requested 1099512676352 bytes) In-Reply-To: <044.b28ef9f55aa85f3be9d617cd7c0f70a5@haskell.org> References: <044.b28ef9f55aa85f3be9d617cd7c0f70a5@haskell.org> Message-ID: <059.e6fb56610a9c397447549f08bbdf7c04@haskell.org> #10682: AArch64: dll-split: out of memory (requested 1099512676352 bytes) ----------------------------------------+---------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Comment (by kgardas): Edward, you are of course right. The symptoms may be the same but fix is completely different since this is heavily #ifdefed OS specific code anyway, so Solaris fix will touch different place anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 19:32:36 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 19:32:36 -0000 Subject: [GHC] #10790: amd64/solaris 11: dll-split: out of memory (requested 1099512676352 bytes) Message-ID: <046.47e31a9b6a306f95c5ab473eb166ad84@haskell.org> #10790: amd64/solaris 11: dll-split: out of memory (requested 1099512676352 bytes) -----------------------------------------+--------------------------------- Reporter: kgardas | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.11 Keywords: | Operating System: Solaris Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+--------------------------------- Sometimes between July 19 and August 11 GHC HEAD build on Solaris 11/AMD64 platform started to fail. The failure looks: {{{ dll-split: out of memory (requested 1099512676352 bytes) gmake[1]: *** [compiler/stage2/dll-split.stamp] Error 1 gmake: *** [all] Error 2 }}} and may be seen here http://haskell.inf.elte.hu/builders/solaris- amd64-head/350/10.html The symptoms of the failure looks similar to #10682 but as this is about ARM64/Linux I rather write separate bug report here since code involved is heavily #ifdefed to be OS specific -- hence also Solaris fix will be different from ARM64/Linux one probably. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 20:26:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 20:26:16 -0000 Subject: [GHC] #10782: Existential variables not scoped? In-Reply-To: <047.163aa6e21fe23b588fdda5e44a010081@haskell.org> References: <047.163aa6e21fe23b588fdda5e44a010081@haskell.org> Message-ID: <062.1e8ae97fc8c25ab94b78fbb6cf7731cf@haskell.org> #10782: Existential variables not scoped? -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => invalid Comment: Ah. After quite a bit more staring at the situation, I now understand. Existential variables are ''not'' added to `tcl_tyvars` directly. But all free variables of anything that is in scope (term-level or type-level) ''are'' added there. Because you can't ever get to a type variable unless it is in scope or something that mentions it is in scope, this is all OK. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 20:45:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 20:45:49 -0000 Subject: [GHC] #10790: amd64/solaris 11: dll-split: out of memory (requested 1099512676352 bytes) In-Reply-To: <046.47e31a9b6a306f95c5ab473eb166ad84@haskell.org> References: <046.47e31a9b6a306f95c5ab473eb166ad84@haskell.org> Message-ID: <061.8047da75f76ed0d7a87b2c12c9269521@haskell.org> #10790: amd64/solaris 11: dll-split: out of memory (requested 1099512676352 bytes) -------------------------------------+------------------------------------- Reporter: kgardas | Owner: kgardas Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.11 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by kgardas): * owner: simonmar => kgardas -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 20:47:51 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 20:47:51 -0000 Subject: [GHC] #10790: amd64/solaris 11: dll-split: out of memory (requested 1099512676352 bytes) In-Reply-To: <046.47e31a9b6a306f95c5ab473eb166ad84@haskell.org> References: <046.47e31a9b6a306f95c5ab473eb166ad84@haskell.org> Message-ID: <061.bc6d20c362e7ac8d5005d9042c3c7bf9@haskell.org> #10790: amd64/solaris 11: dll-split: out of memory (requested 1099512676352 bytes) -------------------------------------+------------------------------------- Reporter: kgardas | Owner: kgardas Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.11 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by kgardas): * status: new => patch Comment: Phab:D1169 contains proposed fix for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 23:03:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 23:03:18 -0000 Subject: [GHC] #10782: Existential variables not scoped? In-Reply-To: <047.163aa6e21fe23b588fdda5e44a010081@haskell.org> References: <047.163aa6e21fe23b588fdda5e44a010081@haskell.org> Message-ID: <062.4fcb9423063e51501bdad937781703db@haskell.org> #10782: Existential variables not scoped? -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Ah yes, I see too. Maybe add a comment with `tcl_tyvars`? And I keep thinking that we could do better by using the level numbers now stored in type variables... just never quite get to it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 24 23:16:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Aug 2015 23:16:38 -0000 Subject: [GHC] #10791: Add a --disable-large-memory-space configure option Message-ID: <044.dad24b52dfdb3ab9a4e1b09182a3fa05@haskell.org> #10791: Add a --disable-large-memory-space configure option -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature | Status: new request | Priority: normal | Milestone: 7.12.1 Component: Build | Version: 7.11 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- GHC recently started using large (1TB) address space on 64 bit systems. This feature is enabled by default but does not work on arm64-linux or amd64-solaris. Even just for testing, it would be nice to be able to disable this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 25 00:47:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Aug 2015 00:47:49 -0000 Subject: [GHC] #10682: AArch64: dll-split: out of memory (requested 1099512676352 bytes) In-Reply-To: <044.b28ef9f55aa85f3be9d617cd7c0f70a5@haskell.org> References: <044.b28ef9f55aa85f3be9d617cd7c0f70a5@haskell.org> Message-ID: <059.1f3c87449c4a337a241516a56ddf4591@haskell.org> #10682: AArch64: dll-split: out of memory (requested 1099512676352 bytes) ----------------------------------------+---------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Comment (by erikd): On aarch64-linux, applying this patch: {{{ diff --git a/rts/sm/HeapAlloc.h b/rts/sm/HeapAlloc.h index c914b5d..90a55d1 100644 --- a/rts/sm/HeapAlloc.h +++ b/rts/sm/HeapAlloc.h @@ -52,7 +52,7 @@ #ifdef USE_LARGE_ADDRESS_SPACE extern W_ mblock_address_space_begin; -# define MBLOCK_SPACE_SIZE ((StgWord)1 << 40) /* 1 TB */ +# define MBLOCK_SPACE_SIZE ((StgWord)1 << 38) /* 1/4 TB */ # define HEAP_ALLOCED(p) ((W_)(p) >= mblock_address_space_begin && \ (W_)(p) < (mblock_address_space_begin + \ MBLOCK_SPACE_SIZE)) }}} fixes the build. @kgardas, does this fix amd64-solaris as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 25 01:19:22 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Aug 2015 01:19:22 -0000 Subject: [GHC] #10791: Add a --disable-large-memory-space configure option In-Reply-To: <044.dad24b52dfdb3ab9a4e1b09182a3fa05@haskell.org> References: <044.dad24b52dfdb3ab9a4e1b09182a3fa05@haskell.org> Message-ID: <059.e0aca0015d071188443974ab8fb307b8@haskell.org> #10791: Add a --disable-large-memory-space configure option -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): The truth table for enabling USE_LARGE_ADDRESS_SPACE should be: {{{ sizeof(void*) command line USE_LARGE_ADDRESS_SPACE 4 - undefined 4 --enable-large-address-space undefined 4 --disable-large-address-space undefined 8 - 1 8 --enable-large-address-space 1 8 --disable-large-address-space undefined }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 25 01:30:53 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Aug 2015 01:30:53 -0000 Subject: [GHC] #10682: AArch64: dll-split: out of memory (requested 1099512676352 bytes) In-Reply-To: <044.b28ef9f55aa85f3be9d617cd7c0f70a5@haskell.org> References: <044.b28ef9f55aa85f3be9d617cd7c0f70a5@haskell.org> Message-ID: <059.abb6e6f76d44adadd1026692b87a5cf2@haskell.org> #10682: AArch64: dll-split: out of memory (requested 1099512676352 bytes) ----------------------------------------+---------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Comment (by erikd): @kgardas has an amd64-solaris fix at Phab:D1169. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 25 01:46:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Aug 2015 01:46:11 -0000 Subject: [GHC] #10791: Add a --disable-large-memory-space configure option In-Reply-To: <044.dad24b52dfdb3ab9a4e1b09182a3fa05@haskell.org> References: <044.dad24b52dfdb3ab9a4e1b09182a3fa05@haskell.org> Message-ID: <059.79a673f70ac8b0dc088c2a73b118513d@haskell.org> #10791: Add a --disable-large-memory-space configure option -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1170 -------------------------------------+------------------------------------- Changes (by erikd): * differential: => Phab:D1170 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 25 02:27:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Aug 2015 02:27:44 -0000 Subject: [GHC] #10682: AArch64: dll-split: out of memory (requested 1099512676352 bytes) In-Reply-To: <044.b28ef9f55aa85f3be9d617cd7c0f70a5@haskell.org> References: <044.b28ef9f55aa85f3be9d617cd7c0f70a5@haskell.org> Message-ID: <059.769d10dfa57f7380adb4890bc46f8a57@haskell.org> #10682: AArch64: dll-split: out of memory (requested 1099512676352 bytes) -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1171 -------------------------------------+------------------------------------- Changes (by erikd): * status: new => patch * differential: => Phab:D1171 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 25 02:28:01 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Aug 2015 02:28:01 -0000 Subject: [GHC] #10791: Add a --disable-large-memory-space configure option In-Reply-To: <044.dad24b52dfdb3ab9a4e1b09182a3fa05@haskell.org> References: <044.dad24b52dfdb3ab9a4e1b09182a3fa05@haskell.org> Message-ID: <059.e7643a4606c9819297164b75f84cf4d9@haskell.org> #10791: Add a --disable-large-memory-space configure option -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: patch Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1170 -------------------------------------+------------------------------------- Changes (by erikd): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 25 02:35:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Aug 2015 02:35:49 -0000 Subject: [GHC] #10377: Remove double negative of ("Unregisterised", "NO") In-Reply-To: <044.31181ac18eac612460803bc88434cef8@haskell.org> References: <044.31181ac18eac612460803bc88434cef8@haskell.org> Message-ID: <059.2ebbad1e37e072d60c807059f68a8a3f@haskell.org> #10377: Remove double negative of ("Unregisterised", "NO") -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by erikd): * status: new => closed * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 25 08:21:01 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Aug 2015 08:21:01 -0000 Subject: [GHC] #10068: Make the runtime reflection API for names, modules, locations more systematic In-Reply-To: <046.e24e266e9d617fc4224d115c2a203db8@haskell.org> References: <046.e24e266e9d617fc4224d115c2a203db8@haskell.org> Message-ID: <061.1cb398ee672999378ea7c0deb721e3c6@haskell.org> #10068: Make the runtime reflection API for names, modules, locations more systematic -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): I will try to follow this example in my DWARF stack tracing work. To recap, it seems like we have the following types, {{{#!hs -- | A Haskell module belonging to a package data Module moduleName :: Module -> String modulePackage :: Module -> Package -- | A Haskell package data Package packageName :: Package -> String packageKey :: Package -> PackageKey -- | A named definition in a Haskell module data Entity entityModule :: Entity -> Module entityName :: Entity -> String }}} Any preferences on where these should live? `GHC.Reflection` seems appropriate but perhaps a bit ambiguous given how overloaded "reflection" now is. In the case of DWARF stacktraces this will require that we are able to produce a `Module` for any given loaded Haskell module. It seems the easiest way to do this would be to simply inject a binding with a predictable name into each module at compile time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 25 08:32:08 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Aug 2015 08:32:08 -0000 Subject: [GHC] #10068: Make the runtime reflection API for names, modules, locations more systematic In-Reply-To: <046.e24e266e9d617fc4224d115c2a203db8@haskell.org> References: <046.e24e266e9d617fc4224d115c2a203db8@haskell.org> Message-ID: <061.689bb93c5ff1d4199a2ad084b901fd70@haskell.org> #10068: Make the runtime reflection API for names, modules, locations more systematic -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): > In the case of DWARF stacktraces this will require that we are able to produce a `Module` for any given loaded Haskell module. It seems the easiest way to do this would be to simply inject a binding with a predictable name into each module at compile time. Yes -- that is exactly what I have done in my `wip/T9858-typeable-spj` branch. I really want to get that branch committed... let's discuss in our call today. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 25 10:36:47 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Aug 2015 10:36:47 -0000 Subject: [GHC] #10792: Bounded Enums [minBound..maxBound] produces runtime error Message-ID: <056.73eb9fb152f83711a842e4b0cfcb2567@haskell.org> #10792: Bounded Enums [minBound..maxBound] produces runtime error -------------------------------------+------------------------------------- Reporter: | Owner: ekmett AlexanderThiemann | Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.10.2 Libraries | Keywords: | Operating System: Linux Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Consider this code: {{{#!hs data MultiHeader = MultiHeaderCacheControl | MultiHeaderConnection | MultiHeaderContentEncoding -- ... deriving (Show, Eq, Enum, Bounded, Generic) instance Hashable MultiHeader multiHeaderCI :: MultiHeader -> CI.CI BS.ByteString multiHeaderCI mh = case mh of MultiHeaderCacheControl -> "Cache-Control" MultiHeaderConnection -> "Connection" MultiHeaderContentEncoding -> "Content-Encoding" -- ... multiHeaderMap :: HM.HashMap (CI.CI BS.ByteString) MultiHeader multiHeaderMap = HM.fromList $ flip map [minBound..maxBound] $ \mh -> (multiHeaderCI mh, mh) }}} (derived from https://github.com/agrafix/Spock/blob/9c19c0159d99783aabf896d2742e231a5e85e0a5/src/Web/Spock/Internal/Wire.hs#L83-L121 ) When the multiHeaderMap accessed, a runtime error on GHC7.10.2 running on *some* [0] [1] Linux architectures is thrown. It does not occur on Mac or the travis build infrastructure [2]. {{{ uncaught exception: ErrorCall (toEnum{MultiHeader}: tag (-12565) is outside of enumeration's range (0,12)) }}} I've marked the bug with 'core libraries', but I am not certain that that's the origin of it. [0]: https://github.com/agrafix/Spock/issues/44 (Hydra / NixOS?) [1]: We've also seen it happen when used in docker with ubuntu:14.04 base image [2]: https://travis-ci.org/agrafix/Spock/builds/76877783 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 25 11:17:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Aug 2015 11:17:30 -0000 Subject: [GHC] #10793: Incorrect blocked on MVar detection Message-ID: <051.7658851bb71506c4b1bae1ee7211ff06@haskell.org> #10793: Incorrect blocked on MVar detection -------------------------------------+------------------------------------- Reporter: | Owner: simonmar NeilMitchell | Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.1 System | Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Given the code: {{{#!hs import Control.Concurrent main = do v <- newEmptyMVar forkFinally (putStrLn $ let x = x in x) (putMVar v) print =<< takeMVar v }}} The spawned thread should raise a {{{NonTermination}}} exception (assuming idle GC), then put it in the MVar {{{v}}}, which should cause the main thread to abort printing {{{Left <>}}}. However, in reality, the main thread aborts with {{{Exception: thread blocked indefinitely in an MVar operation}}}. My debugging shows that the spawned thread raises {{{NonTermination}}} and at the same time the main thread raises {{{BlockedIndefinitelyOnMVar}}}. Of course, the main thread is not really blocked on the exception, and after the finally bit runs, the MVar is filled. Adding tracing shows that the {{{putMVar}}} is called. Hypothesis is that the GC notices it can raise the non-termination exception, and then opportunistically excludes that thread from further GC scanning, and detects the MVar is unreferenced, raising the subsequent exception. Of course, given you can catch the exception, that isn't safe. Roman Leshchinskiy worries that in the wrong circumstances the MVar might really be being GC'd and thus could corrupt memory. This issue was detected while debugging an error in the Shake build system for GHC itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 25 11:27:45 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Aug 2015 11:27:45 -0000 Subject: [GHC] #10792: Bounded Enums [minBound..maxBound] produces runtime error In-Reply-To: <056.73eb9fb152f83711a842e4b0cfcb2567@haskell.org> References: <056.73eb9fb152f83711a842e4b0cfcb2567@haskell.org> Message-ID: <071.e99049cb70149372ea37fc1a37ac5aa2@haskell.org> #10792: Bounded Enums [minBound..maxBound] produces runtime error -------------------------------------+------------------------------------- Reporter: | Owner: ekmett AlexanderThiemann | Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Since it's a runtime error, can you offer a `Main` module so that if you compile and run the example you get the exception? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 25 11:50:54 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Aug 2015 11:50:54 -0000 Subject: [GHC] #10464: ghc 7.8.4 on arm In-Reply-To: <051.d5878ed901f03828231ecea66d3e9618@haskell.org> References: <051.d5878ed901f03828231ecea66d3e9618@haskell.org> Message-ID: <066.fd88c428bbd74beedb8878cbf4f4b57b@haskell.org> #10464: ghc 7.8.4 on arm ---------------------------------+-------------------------------- Reporter: andrewufrank | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+-------------------------------- Comment (by nomeata): This seems to affect packages that want to use doctests, as can be seen in this build log: https://buildd.debian.org/status/fetch.php?pkg=haskell- bytes&arch=armhf&ver=0.15.0.1-2&stamp=1440503305 See also #10376. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 25 12:34:59 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Aug 2015 12:34:59 -0000 Subject: [GHC] #10376: arm/linux linking failure In-Reply-To: <044.29ac411aa184ff9b10d3766853c9a35d@haskell.org> References: <044.29ac411aa184ff9b10d3766853c9a35d@haskell.org> Message-ID: <059.55e2703f3fe86848738b6b6392e423d1@haskell.org> #10376: arm/linux linking failure -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10464 | Differential Revisions: -------------------------------------+--------------------------------- Changes (by thomie): * architecture: Unknown/Multiple => arm * related: => #10464 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 25 16:14:39 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Aug 2015 16:14:39 -0000 Subject: [GHC] #10661: Regression: hp2ps reports `integer unexpected` on new style package keys In-Reply-To: <045.9c4a37e2fa0ae7c34e598ac5ff3e0cab@haskell.org> References: <045.9c4a37e2fa0ae7c34e598ac5ff3e0cab@haskell.org> Message-ID: <060.9c7e93a3715bb8e252029610ae9f94c5@haskell.org> #10661: Regression: hp2ps reports `integer unexpected` on new style package keys -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.12.1 Component: Profiling | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | concurrent/prog002/concprog002 Blocked By: | Blocking: Related Tickets: #10550 | Differential Revisions: Phab:D1175 -------------------------------------+------------------------------------- Changes (by Yuras): * status: new => patch * differential: => Phab:D1175 Comment: `PackageKey` is a package name for wired-in packages, and a hash for other packages. So lets fix `hp2ps`. Probably better solution should be rewriting it in haskell... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 25 19:13:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Aug 2015 19:13:50 -0000 Subject: [GHC] #10284: Create a dedicated `TypeError` exception type In-Reply-To: <047.839fde5ec581c7ee24adc8fc2d4d35b0@haskell.org> References: <047.839fde5ec581c7ee24adc8fc2d4d35b0@haskell.org> Message-ID: <062.061dcc144f4c1875fb400e5e7abf4b52@haskell.org> #10284: Create a dedicated `TypeError` exception type -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: kanetw Type: feature request | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: phab:D866 -------------------------------------+------------------------------------- Changes (by kanetw): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 25 19:16:36 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Aug 2015 19:16:36 -0000 Subject: [GHC] #10284: Create a dedicated `TypeError` exception type In-Reply-To: <047.839fde5ec581c7ee24adc8fc2d4d35b0@haskell.org> References: <047.839fde5ec581c7ee24adc8fc2d4d35b0@haskell.org> Message-ID: <062.21a2d8442df5cbab21713e0fa8fa4c75@haskell.org> #10284: Create a dedicated `TypeError` exception type -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: kanetw Type: feature request | Status: closed Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_run/T10284 Blocked By: | Blocking: Related Tickets: | Differential Revisions: phab:D866 -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => typecheck/should_run/T10284 * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 25 19:49:58 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Aug 2015 19:49:58 -0000 Subject: [GHC] #10790: amd64/solaris 11: dll-split: out of memory (requested 1099512676352 bytes) In-Reply-To: <046.47e31a9b6a306f95c5ab473eb166ad84@haskell.org> References: <046.47e31a9b6a306f95c5ab473eb166ad84@haskell.org> Message-ID: <061.b692f7a8d7b8ae54759b29cbf5fedfd3@haskell.org> #10790: amd64/solaris 11: dll-split: out of memory (requested 1099512676352 bytes) -------------------------------------+------------------------------------- Reporter: kgardas | Owner: kgardas Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.11 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Karel Gardas ): In [changeset:"b78494eee787bdc0f9cc263b773638dc7db3482f/ghc" b78494e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b78494eee787bdc0f9cc263b773638dc7db3482f" fix 64bit two-stage allocator on Solaris/AMD64 platform (#10790) Test Plan: tested on Solaris 11/AMD64 when previous build failed Reviewers: bgamari, austin, simonmar, gcampax, ezyang Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1169 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 25 19:51:01 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Aug 2015 19:51:01 -0000 Subject: [GHC] #10639: Tight (non-allocating) loop freezes the scheduler In-Reply-To: <048.3130b8c9dae40d4cc95f52d78c185152@haskell.org> References: <048.3130b8c9dae40d4cc95f52d78c185152@haskell.org> Message-ID: <063.f1acfaf47d7ee0ef63d86ec421730bdd@haskell.org> #10639: Tight (non-allocating) loop freezes the scheduler -------------------------------------+------------------------------------- Reporter: gizmo.mk0 | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1127 -------------------------------------+------------------------------------- Comment (by Phyx-): Can we close this and #367 or is there something else needed other than documentation? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 25 20:29:16 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Aug 2015 20:29:16 -0000 Subject: [GHC] #10794: Extension request: "where" clauses in type signatures Message-ID: <044.9a4c4d98dcd641a7419dce28f41123ac@haskell.org> #10794: Extension request: "where" clauses in type signatures -------------------------------------+------------------------------------- Reporter: danso | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Some type signatures could be simplified by separating certain elements, either because they are lengthy and can be expressed simpler, to better express intention, or because they are repetitive. A "WhereSignatures" extension would allow for type signatures like the following: {{{#!hs fold :: f -> [a] -> a where f :: a -> a -> a -- expresses intention more clearly than: fold :: (a -> a -> a) -> [a] -> a union :: a -> a -> a where a :: Map.Map k v -- much shorter/more readable than: union :: Map.Map k v -> Map.Map k v -> Map.Map k v }}} Or maybe even: {{{#!hs fmap :: (a -> b) -> f a -> f b where (Functor f) -- arguably prettier than: fmap :: (Functor f) => (a -> b) -> f a -> f b }}} This minor syntactic sugar is essentially equivalent to local "type" definitions, which provides an advantage of making the type's purpose more clear. This seems like a natural development on what the type checker can do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 25 20:47:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Aug 2015 20:47:40 -0000 Subject: [GHC] #10794: Extension request: "where" clauses in type signatures In-Reply-To: <044.9a4c4d98dcd641a7419dce28f41123ac@haskell.org> References: <044.9a4c4d98dcd641a7419dce28f41123ac@haskell.org> Message-ID: <059.244b1f152f8fbaa13ee27f6ac7fbe33a@haskell.org> #10794: Extension request: "where" clauses in type signatures -------------------------------------+------------------------------------- Reporter: danso | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): {{{#!hs fold :: f -> [a] -> a where f :: a -> a -> a }}} is certainly confusing, because in the first line `f` is used like a type, but in the second, `f` is used like a value (or `a -> a -> a` is used like a kind Maybe you meant {{{#!hs fold :: f -> [a] -> a where f = a -> a -> a }}} which could be extended to allow {{{#!hs fold :: f -> [a] -> a where f :: * f = a -> a -> a }}} I?m sure the type level programming wizards and dependently typed programmers will have the greatest need for such an extension, and have a good opinion here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 25 21:25:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Aug 2015 21:25:27 -0000 Subject: [GHC] #10661: Regression: hp2ps reports `integer unexpected` on new style package keys In-Reply-To: <045.9c4a37e2fa0ae7c34e598ac5ff3e0cab@haskell.org> References: <045.9c4a37e2fa0ae7c34e598ac5ff3e0cab@haskell.org> Message-ID: <060.a62a53fbb39bab1fccb8ca2fda5ec46a@haskell.org> #10661: Regression: hp2ps reports `integer unexpected` on new style package keys -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.12.1 Component: Profiling | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | concurrent/prog002/concprog002 Blocked By: | Blocking: Related Tickets: #10550 | Differential Revisions: Phab:D1175 -------------------------------------+------------------------------------- Comment (by thomie): Is this fix still needed? I installed a package in the user package database with ghc-7.11.20150809, and its package key was `rando_7xz1XSr7300DdrwOq0nUDQ`. Note the `rando` prefix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 25 22:21:51 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Aug 2015 22:21:51 -0000 Subject: [GHC] #10791: Add a --disable-large-memory-space configure option In-Reply-To: <044.dad24b52dfdb3ab9a4e1b09182a3fa05@haskell.org> References: <044.dad24b52dfdb3ab9a4e1b09182a3fa05@haskell.org> Message-ID: <059.d0c65f21f583a150dd425faff269140c@haskell.org> #10791: Add a --disable-large-memory-space configure option -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: patch Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1170 -------------------------------------+------------------------------------- Comment (by Erik de Castro Lopo ): In [changeset:"fba724ccabd295fc37e71ba6c4f892822a831d19/ghc" fba724cc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fba724ccabd295fc37e71ba6c4f892822a831d19" configure.ac: Allow disabling of large-address-space Recent changes (commit 0d1a8d09f4) for 64 bit platforms allowed GHC to mmap one huge (currently 1 terrabyte) memory region from which to do its own allocations. This is enabled by default, but it would be nice (even just from the point of view of testing) to be able to disable this at configure time. Test Plan: configure and grep mk/config.h for USE_LARGE_ADDRESS_SPACE Reviewers: austin, ezyang, bgamari, rwbarton Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1170 GHC Trac Issues: #10791 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 25 22:41:23 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Aug 2015 22:41:23 -0000 Subject: [GHC] #10794: Extension request: "where" clauses in type signatures In-Reply-To: <044.9a4c4d98dcd641a7419dce28f41123ac@haskell.org> References: <044.9a4c4d98dcd641a7419dce28f41123ac@haskell.org> Message-ID: <059.bc06a3234e63ddc8f218919ba0e45432@haskell.org> #10794: Extension request: "where" clauses in type signatures -------------------------------------+------------------------------------- Reporter: danso | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by danso: Old description: > Some type signatures could be simplified by separating certain elements, > either because they are lengthy and can be expressed simpler, to better > express intention, or because they are repetitive. A "WhereSignatures" > extension would allow for type signatures like the following: > > {{{#!hs > fold :: f -> [a] -> a > where f :: a -> a -> a > > -- expresses intention more clearly than: > fold :: (a -> a -> a) -> [a] -> a > > union :: a -> a -> a > where a :: Map.Map k v > > -- much shorter/more readable than: > union :: Map.Map k v -> Map.Map k v -> Map.Map k v > }}} > > Or maybe even: > > {{{#!hs > fmap :: (a -> b) -> f a -> f b > where (Functor f) > > -- arguably prettier than: > fmap :: (Functor f) => (a -> b) -> f a -> f b > }}} > > This minor syntactic sugar is essentially equivalent to local "type" > definitions, which provides an advantage of making the type's purpose > more clear. This seems like a natural development on what the type > checker can do. New description: Some type signatures could be simplified by separating certain elements, either because they are lengthy and can be expressed simpler, to better express intention, or because they are repetitive. A "WhereSignatures" extension would allow for type signatures like the following: {{{#!hs fold :: f -> [a] -> a where f = a -> a -> a -- expresses intention more clearly than: fold :: (a -> a -> a) -> [a] -> a union :: a -> a -> a where a = Map.Map k v -- much shorter/more readable than: union :: Map.Map k v -> Map.Map k v -> Map.Map k v }}} Or maybe even: {{{#!hs fmap :: (a -> b) -> f a -> f b where (Functor f) -- arguably prettier than: fmap :: (Functor f) => (a -> b) -> f a -> f b }}} This minor syntactic sugar is essentially equivalent to local "type" definitions, which provides an advantage of making the type's purpose more clear. This seems like a natural development on what the type checker can do. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 25 22:44:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Aug 2015 22:44:25 -0000 Subject: [GHC] #10794: Extension request: "where" clauses in type signatures In-Reply-To: <044.9a4c4d98dcd641a7419dce28f41123ac@haskell.org> References: <044.9a4c4d98dcd641a7419dce28f41123ac@haskell.org> Message-ID: <059.1a9c4b8501f72f9b00127d4069a61b2c@haskell.org> #10794: Extension request: "where" clauses in type signatures -------------------------------------+------------------------------------- Reporter: danso | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by danso): Replying to [comment:1 nomeata]: > {{{#!hs > fold :: f -> [a] -> a > where f :: a -> a -> a > }}} > is certainly confusing, because in the first line `f` is used like a type, but in the second, `f` is used like a value (or `a -> a -> a` is used like a kind > > Maybe you meant > {{{#!hs > fold :: f -> [a] -> a > where f = a -> a -> a > }}} > which could be extended to allow > > {{{#!hs > fold :: f -> [a] -> a > where f :: * > f = a -> a -> a > }}} > > I?m sure the type level programming wizards and dependently typed programmers will have the greatest need for such an extension, and have a good opinion here. Good catch. I agree that your suggestion makes more sense and have changed the ticket accordingly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 25 23:31:17 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Aug 2015 23:31:17 -0000 Subject: [GHC] #10795: Upgrade gcc in 7.10 Message-ID: <047.10f0f15eefcc41678a1092a9c9b6dd30@haskell.org> #10795: Upgrade gcc in 7.10 -------------------------------------+------------------------------------- Reporter: joozek78 | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.3 Component: Build | Version: 7.10.2 System | Keywords: | Operating System: Windows Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- See #10777. The patch submitted by snoyberg won't work unless gcc is upgraded (at least to 4.7.0 I think - take a look at [[http://sourceforge.net/p/mingw-w64/mailman/message/29339395/|this mail thread]]). That's because response files are not used properly by older gcc. '''gcc was upgraded for 7.12 in #10726 so this just needs to be backported''' -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 25 23:32:07 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Aug 2015 23:32:07 -0000 Subject: [GHC] #10795: Upgrade gcc in 7.10 In-Reply-To: <047.10f0f15eefcc41678a1092a9c9b6dd30@haskell.org> References: <047.10f0f15eefcc41678a1092a9c9b6dd30@haskell.org> Message-ID: <062.e4f4e934b8b75c1132d4826d6f917f26@haskell.org> #10795: Upgrade gcc in 7.10 -------------------------------------+------------------------------------- Reporter: joozek78 | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10777 #10726 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by joozek78): * related: => #10777 #10726 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 25 23:36:12 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Aug 2015 23:36:12 -0000 Subject: [GHC] #10726: Upgrade MingW-w64 distributions for windows In-Reply-To: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> References: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> Message-ID: <059.2b95447909d749ae01c02734ef347e31@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: merge Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #9014 | Differential Revisions: Phab:D1123 #10435 | -------------------------------------+------------------------------------- Changes (by thomie): * status: closed => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 25 23:39:14 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Aug 2015 23:39:14 -0000 Subject: [GHC] #10726: Upgrade MingW-w64 distributions for windows In-Reply-To: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> References: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> Message-ID: <059.c9a0edabe6cdb2834d8f1d2c6d6a7955@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: merge Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #9014 | Differential Revisions: Phab:D1123 #10435 | -------------------------------------+------------------------------------- Changes (by thomie): * milestone: 7.12.1 => 7.10.3 Comment: In #10795, user joozek78 asks for a merge to 7.10 of the above patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 25 23:40:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Aug 2015 23:40:06 -0000 Subject: [GHC] #10795: Upgrade gcc in 7.10 In-Reply-To: <047.10f0f15eefcc41678a1092a9c9b6dd30@haskell.org> References: <047.10f0f15eefcc41678a1092a9c9b6dd30@haskell.org> Message-ID: <062.0501fb6e7d589e597f58e4f54ba55b59@haskell.org> #10795: Upgrade gcc in 7.10 -------------------------------------+------------------------------------- Reporter: joozek78 | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.10.2 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10726 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: #10777 #10726 => #10726 Comment: I set #10726 to merge status for you, so it won't be lost. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 25 23:41:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Aug 2015 23:41:24 -0000 Subject: [GHC] #10796: Illegal data constructor name: `fromList' ... When splicing a TH expression Message-ID: <045.67153471687796395f900337ba5220e7@haskell.org> #10796: Illegal data constructor name: `fromList' ... When splicing a TH expression -------------------------------------+------------------------------------- Reporter: erisco | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.8.3 Haskell | Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- At the end is a log of my ghci session reproducing the issue. It is expected that the splice should succeed, but GHC complains "Illegal data constructor name: `fromList' ... When splicing a TH expression". Full definitions being used can be found at http://hackage.haskell.org/package/regex-tdfa-quasiquoter-0.2.0.0 . Briefly, this is the splice being used. {{{#!hs [e|patternToRegex $patternExp $compOptsExp $execOptsExp|] where patternExp = dataToExpQ (const Nothing) pattern compOptsExp = dataToExpQ (const Nothing) compOpts execOptsExp = dataToExpQ (const Nothing) execOpts }}} Data and Typeable instances are derived (using -XStandaloneDeriving -XDeriveDataTypeable) as orphan instances in the Internal module. The issue occurs when using bracket expressions (in POSIX regular expressions). There may be other cases but I have not uncovered them. {{{ > ghci GHCi, version 7.8.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. >>> :set -XQuasiQuotes >>> import Text.Regex.TDFA.QuasiQuoter >>> :t [re|;[a]|] Loading package transformers-0.3.0.0 ... 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 containers-0.5.5.1 ... linking ... done. Loading package mtl-2.1.3.1 ... linking ... done. Loading package regex-base-0.93.2 ... linking ... done. Loading package text-1.2.0.3 ... linking ... done. Loading package parsec-3.1.9 ... linking ... done. Loading package regex-tdfa-1.2.0 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package regex-tdfa-quasiquoter-0.2.0.0 ... linking ... done. :1:5: Illegal data constructor name: `fromList' When splicing a TH expression: Text.Regex.TDFA.TDFA.patternToRegex (GHC.Tuple.(,) (Text.Regex.TDFA.Pattern.POr ((GHC.Types.:) (Text.Regex.TDFA.Pattern.PConcat ((GHC.Types.:) (Text.Regex.TDFA.Pattern.PAny (Text.Regex.TDFA.Common.DoPa 1) (Text.Regex.TDFA.Pattern.PatternSet (Data.Maybe.Just (Data.Set.Base.fromList ((GHC.Types.:) 'a' GHC.Types.[]))) Data.Maybe.Nothing Data.Maybe.Nothing Data.Maybe.Nothing)) GHC.Types.[])) GHC.Types.[])) (GHC.Tuple.(,) 0 (Text.Regex.TDFA.Common.DoPa 1))) (Text.Regex.TDFA.Common.CompOption GHC.Types.True GHC.Types.True GHC.Types.True GHC.Types.True GHC.Types.False) (Text.Regex.TDFA.Common.ExecOption GHC.Types.True) >>> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 26 00:04:25 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Aug 2015 00:04:25 -0000 Subject: [GHC] #10726: Upgrade MingW-w64 distributions for windows In-Reply-To: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> References: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> Message-ID: <059.e1972ac643c931f739ab8f8c30fc5b05@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: merge Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #9014 | Differential Revisions: Phab:D1123 #10435 | -------------------------------------+------------------------------------- Changes (by snoyberg): * cc: snoyberg (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 26 00:33:48 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Aug 2015 00:33:48 -0000 Subject: [GHC] #10726: Upgrade MingW-w64 distributions for windows In-Reply-To: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> References: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> Message-ID: <059.309974b42265dfdb4d52a087269c0ab7@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: merge Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #9014 | Differential Revisions: Phab:D1123 #10435 | -------------------------------------+------------------------------------- Changes (by joozek78): * cc: joozek78 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 26 00:52:05 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Aug 2015 00:52:05 -0000 Subject: [GHC] #10714: After implementing new installed package ID (hash of sdist), get rid of package keys In-Reply-To: <045.13deae8316589a147d8e83f0a90ec4d1@haskell.org> References: <045.13deae8316589a147d8e83f0a90ec4d1@haskell.org> Message-ID: <060.8b4015fe1dbbede917a9a46072acba81@haskell.org> #10714: After implementing new installed package ID (hash of sdist), get rid of package keys -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.10.2 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): Here is a complication: what should shadowing do in this world? Of course, within a package database, shadowing cannot occur, because there can only ever be one entry per IPID, whereas shadowing occurred when there were two entries with differing IPIDs but identical package keys. However, there is now a thorny problem of what should be done if the user and global package database both have an entry for the same IPID! Previously, GHC assumed that the ABIs are the same, and thus they are interchangeable; however, it is possible for this invariant to be broken. What it seems GHC should do is check the ABI of the package in question, and if they match filter out as before. However, if the ABIs do not match, we can either (1) complain loudly, or (2) shadow all prior references to the IPID so that we can safely use the newer IPID. The second possibility seems like a lot of complication for a case that really shouldn't happen, so let's not do it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 26 02:58:04 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Aug 2015 02:58:04 -0000 Subject: [GHC] #10795: Upgrade gcc in 7.10 In-Reply-To: <047.10f0f15eefcc41678a1092a9c9b6dd30@haskell.org> References: <047.10f0f15eefcc41678a1092a9c9b6dd30@haskell.org> Message-ID: <062.721c0a4f7470fbce5137ad7a4ad7a6af@haskell.org> #10795: Upgrade gcc in 7.10 -------------------------------------+------------------------------------- Reporter: joozek78 | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.10.2 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10726 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Upgrading gcc in a point release is kind of scary, but if it's necessary and just on Windows... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 26 07:38:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Aug 2015 07:38:31 -0000 Subject: [GHC] #10794: Extension request: "where" clauses in type signatures In-Reply-To: <044.9a4c4d98dcd641a7419dce28f41123ac@haskell.org> References: <044.9a4c4d98dcd641a7419dce28f41123ac@haskell.org> Message-ID: <059.cca2981d909f51d34b08631642d9f4a0@haskell.org> #10794: Extension request: "where" clauses in type signatures -------------------------------------+------------------------------------- Reporter: danso | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): You can today say {{{ fold :: (f ~ a -> a -> a) => f -> [a] -> [a] }}} which does the job reasonably. I doubt it's worth doing more. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 26 08:04:00 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Aug 2015 08:04:00 -0000 Subject: [GHC] #10796: Illegal data constructor name: `fromList' ... When splicing a TH expression In-Reply-To: <045.67153471687796395f900337ba5220e7@haskell.org> References: <045.67153471687796395f900337ba5220e7@haskell.org> Message-ID: <060.f588298f0b3603c842a59e5f7a533f57@haskell.org> #10796: Illegal data constructor name: `fromList' ... When splicing a TH expression -------------------------------------+------------------------------------- Reporter: erisco | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): This could be the `regex-tdfa-quasiquoter` package generating illegal Haskell, no? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 26 09:32:06 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Aug 2015 09:32:06 -0000 Subject: [GHC] #10661: Regression: hp2ps reports `integer unexpected` on new style package keys In-Reply-To: <045.9c4a37e2fa0ae7c34e598ac5ff3e0cab@haskell.org> References: <045.9c4a37e2fa0ae7c34e598ac5ff3e0cab@haskell.org> Message-ID: <060.788be405f83c5916f7574644f9fa71b1@haskell.org> #10661: Regression: hp2ps reports `integer unexpected` on new style package keys -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.12.1 Component: Profiling | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | concurrent/prog002/concprog002 Blocked By: | Blocking: Related Tickets: #10550 | Differential Revisions: Phab:D1175 -------------------------------------+------------------------------------- Comment (by Yuras): Replying to [comment:4 thomie]: > Is this fix still needed? I installed a package in the user package database with ghc-7.11.20150809, and its package key was `rando_7xz1XSr7300DdrwOq0nUDQ`. Note the `rando` prefix. AFAIK, `Cabal` is responsible generating package keys, see https://github.com/haskell/cabal/pull/2671 Probably you are using old version of `Cabal`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 26 10:34:52 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Aug 2015 10:34:52 -0000 Subject: [GHC] #1830: Automatic derivation of Lift In-Reply-To: <044.3eb409743bc4021eb94e63cb46f573bc@haskell.org> References: <044.3eb409743bc4021eb94e63cb46f573bc@haskell.org> Message-ID: <059.7cdabba8fff4292efe3187086c025d1d@haskell.org> #1830: Automatic derivation of Lift -------------------------------------+------------------------------------- Reporter: guest | Owner: | RyanGlScott Type: feature request | Status: new Priority: normal | Milestone: ? Component: Template Haskell | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1168 -------------------------------------+------------------------------------- Comment (by simonpj): I'm not dead set against this (adding new auto-derived classes doesn't interact with anything), but it does impose a little extra maintenance burden to keep it all working and you can get nearly the same behaviour with a (perhaps enhance) `th-lift` library. It would seem more persuasive if there was more than one advocate for it. Is there a large constituency of TH users who will benefit from this? Data from Hackage might be illuminating... how many `Lift` instances exist? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 26 12:07:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Aug 2015 12:07:28 -0000 Subject: [GHC] #10794: Extension request: "where" clauses in type signatures In-Reply-To: <044.9a4c4d98dcd641a7419dce28f41123ac@haskell.org> References: <044.9a4c4d98dcd641a7419dce28f41123ac@haskell.org> Message-ID: <059.328a498fe1733fb5f30f6f769c4ab9a2@haskell.org> #10794: Extension request: "where" clauses in type signatures -------------------------------------+------------------------------------- Reporter: danso | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:4 simonpj]: > {{{ > fold :: (f ~ a -> a -> a) > => f -> [a] -> [a] > }}} But doing this changes type inference characteristics, by introducing an equality and making some type variables untouchable. This was pointed out in an earlier bug (sadly, I can't remember any search terms) that highlighted a case where the static semantics of using this sort of trick was different than the expanded form. The place I've wanted a feature like this most is when writing intricate type families. But there, it would be necessary to allow local type family definitions in the `where` clause. All that said, I'm ambivalent about this proposal as stated. It would be useful. But does Simon's trick work often enough? Is it worth specifying, developing, and maintaining this? I'm not sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 26 12:41:02 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Aug 2015 12:41:02 -0000 Subject: [GHC] #10796: Illegal data constructor name: `fromList' ... When splicing a TH expression In-Reply-To: <045.67153471687796395f900337ba5220e7@haskell.org> References: <045.67153471687796395f900337ba5220e7@haskell.org> Message-ID: <060.e5603f13ecafbcfea1e98d4a4b45de12@haskell.org> #10796: Illegal data constructor name: `fromList' ... When splicing a TH expression -------------------------------------+------------------------------------- Reporter: erisco | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): A little poking through shows me that this is an infelicity in the containers library. The splice above calls `Language.Haskell.TH.Quote.dataToQa`, which performs lifting (in the sense of TH's `lift` operation and `Lift` class) based on a `Data` instance. The data involved includes a `Data.Set.Set`. And `Set`'s `Data` instance reads, in part {{{ instance (Data a, Ord a) => Data (Set a) where toConstr _ = fromListConstr fromListConstr :: Constr fromListConstr = mkConstr setDataType "fromList" [] Prefix }}} Note that the "constructor" is named `fromList`. But this is a lie, of course. It's done to preserve abstraction, which is a laudable goal, so I'm not calling it a bug. An easy solution here would be to generalize `dataToQa` to check if it's given a data constructor or just a function and react accordingly. It really should be getting a constructor, but there seems to be no harm in allowing `Data` instances to lie like this and continue gracefully. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 26 12:43:40 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Aug 2015 12:43:40 -0000 Subject: [GHC] #10794: Extension request: "where" clauses in type signatures In-Reply-To: <044.9a4c4d98dcd641a7419dce28f41123ac@haskell.org> References: <044.9a4c4d98dcd641a7419dce28f41123ac@haskell.org> Message-ID: <059.14e01ed288874f59c33b8df53044d43d@haskell.org> #10794: Extension request: "where" clauses in type signatures -------------------------------------+------------------------------------- Reporter: danso | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I don't think it changes the type inference characteristics. Can you give an example? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 26 12:56:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Aug 2015 12:56:10 -0000 Subject: [GHC] #10794: Extension request: "where" clauses in type signatures In-Reply-To: <044.9a4c4d98dcd641a7419dce28f41123ac@haskell.org> References: <044.9a4c4d98dcd641a7419dce28f41123ac@haskell.org> Message-ID: <059.f39c431d02c3f4901f06d9d935459293@haskell.org> #10794: Extension request: "where" clauses in type signatures -------------------------------------+------------------------------------- Reporter: danso | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): No, I don't have one. But I'm sure that there was a ticket complaining about the weirdness of using your trick. However, several minutes of looking through a bunch of tickets has yielded nothing. Maybe I'm imagining things. Until we have evidence of the failure, I agree that we should consider your trick to be a suitable encoding of the proposed idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 26 17:41:18 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Aug 2015 17:41:18 -0000 Subject: [GHC] #1830: Automatic derivation of Lift In-Reply-To: <044.3eb409743bc4021eb94e63cb46f573bc@haskell.org> References: <044.3eb409743bc4021eb94e63cb46f573bc@haskell.org> Message-ID: <059.c4727f356022834350bcc7f2aa8d64f7@haskell.org> #1830: Automatic derivation of Lift -------------------------------------+------------------------------------- Reporter: guest | Owner: | RyanGlScott Type: feature request | Status: new Priority: normal | Milestone: ? Component: Template Haskell | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1168 -------------------------------------+------------------------------------- Comment (by RyanGlScott): According to [http://packdeps.haskellers.com/reverse/th-lift packdeps], 32 libraries immediately depend on `th-lift`. Doing a grep of [https://github.com/bitemyapp/hackage-packages hackage-packages] for files that contain both {{{Language.Haskell.TH.Syntax}}} and {{{instance Lift }}} reveals that these additional libraries define their own {{{Lift}}} instances: {{{ persistent-template shakespeare instant-generics yesod-core sqlite-simple-typed generic-deriving Euterpea regular mysql-simple-typed cake3 lighttpd-conf postgresql-simple-typed type pcre-heavy myTestlll multirec-alt-deriver yesod-routes type-level-tf debian vimus named-records module-management Contract grammar-combinators groundhog-th api-tools Webrexp Webrexp type-level web-routes-quasi monad-logger QuasiText ta logging-facade }}} This obviously isn't scientifically rigorous, as there is a chance that the {{{instance Lift}}} could be using some other {{{Lift}}}, or that the {{{Lift}}} instances in those packages wouldn't be derivable in the first place. But this at least gives an approximation of how much impact {{{deriving Lift}}} might have. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 26 18:49:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Aug 2015 18:49:24 -0000 Subject: [GHC] #10797: Kind-level functional dependencies are not resolved properly Message-ID: <046.e5566984a246d66127e6e59197588043@haskell.org> #10797: Kind-level functional dependencies are not resolved properly -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Hello! Let's consider such funny class and its instances. {{{ {-# LANGUAGE PolyKinds #-} ... class BaseType (a :: k) (b :: l) | a -> b, k -> l where baseType :: Proxy a -> Proxy b instance BaseType (a :: j -> k) (out :: l) => BaseType (a (t :: j) :: k) (out :: l) }}} The instance does not compile: {{{ Illegal instance declaration for ?BaseType (a t) out? The liberal coverage condition fails in class ?BaseType? for functional dependency: ?k -> l? Reason: lhs type ?k? does not determine rhs type ?l? In the instance declaration for ?BaseType (a (t :: j) :: k) (out :: l)? }}} While the LHS determines the RHS. The problem is that it seems, that GHC doesn't infer the functional dependency of {{{k ~> l}}} from the dependency {{{j -> k ~> l}}}.. I've used a {{{~>}}} arrow to indicate fundeps. Is this a bug or am I missing something? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 26 18:49:49 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Aug 2015 18:49:49 -0000 Subject: [GHC] #10797: Kind-level functional dependencies are not resolved properly In-Reply-To: <046.e5566984a246d66127e6e59197588043@haskell.org> References: <046.e5566984a246d66127e6e59197588043@haskell.org> Message-ID: <061.14705c23f5e41a9fc55943aa9e3df1c4@haskell.org> #10797: Kind-level functional dependencies are not resolved properly -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by danilo2: Old description: > Hello! Let's consider such funny class and its instances. > > {{{ > {-# LANGUAGE PolyKinds #-} > ... > > class BaseType (a :: k) (b :: l) | a -> b, k -> l where > baseType :: Proxy a -> Proxy b > > instance BaseType (a :: j -> k) (out :: l) => BaseType (a (t :: > j) :: k) (out :: l) > }}} > > The instance does not compile: > {{{ > Illegal instance declaration for ?BaseType (a t) out? > The liberal coverage condition fails in class ?BaseType? > for functional dependency: ?k -> l? > Reason: lhs type ?k? does not determine rhs type ?l? > In the instance declaration for > ?BaseType (a (t :: j) :: k) (out :: l)? > }}} > > While the LHS determines the RHS. The problem is that it seems, that GHC > doesn't infer the functional dependency of {{{k ~> l}}} from the > dependency {{{j -> k ~> l}}}.. I've used a {{{~>}}} arrow to indicate > fundeps. Is this a bug or am I missing something? New description: Hello! Let's consider such funny class and its instances. {{{ {-# LANGUAGE PolyKinds #-} ... class BaseType (a :: k) (b :: l) | a -> b, k -> l where baseType :: Proxy a -> Proxy b instance BaseType (a :: j -> k) (out :: l) => BaseType (a (t :: j) :: k) (out :: l) }}} The instance does not compile: {{{ Illegal instance declaration for ?BaseType (a t) out? The liberal coverage condition fails in class ?BaseType? for functional dependency: ?k -> l? Reason: lhs type ?k? does not determine rhs type ?l? In the instance declaration for ?BaseType (a (t :: j) :: k) (out :: l)? }}} While the LHS determines the RHS. The problem is that it seems, that GHC doesn't infer the functional dependency of {{{k ~> l}}} from the dependency {{{j -> k ~> l}}}.. I've used a {{{~>}}} arrow to indicate fundeps. Is this a bug or am I missing something? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 26 19:05:04 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Aug 2015 19:05:04 -0000 Subject: [GHC] #10797: Kind-level functional dependencies are not resolved properly In-Reply-To: <046.e5566984a246d66127e6e59197588043@haskell.org> References: <046.e5566984a246d66127e6e59197588043@haskell.org> Message-ID: <061.0a290b9dbfdadb5bc460e0eee032e6a9@haskell.org> #10797: Kind-level functional dependencies are not resolved properly -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by danilo2): As an related question - I'm trying to determine the "base type" of a value. I mean, for {{{Proxy Int}}} I want to get {{{Proxy Int}}} but for something like {{{Proxy :: Maybe a}}} (for a known {{{a}}}) I want to get {{{Proxy :: Maybe}}}. I was trying to do this using closed Type Families as well, but without success: {{{ type family BaseTypeTF (t :: *) where BaseTypeTF (Proxy ( (a :: k -> l) (b :: k) )) = BaseTypeTF (Proxy (a :: k -> l) ) BaseTypeTF (Proxy (a :: x) ) = Proxy (a :: x) }}} error: {{{ Family instance purports to bind type variable ?k? but the real LHS (expanding synonyms) is: BaseTypeTF (Proxy (a b)) = ... In the equations for closed type family ?BaseTypeTF? In the type family declaration for ?BaseTypeTF? }}} That could be understandable for two reasons (but I'm not sure if that are good guesses): 1) We've go no mechanism like OverlappingInstances in TypeFamilies, but on the other hand closed type families provides us with similar functionality, but for a closed world, which is fine in this case 2) We've got no syntax to explicitly type the result of this family, because it's kind is {{{*}}}, but it is in fact {{{Proxy :: something}}}, which we are impossible to type if GHC has any ambiguity (which again maybe not related to this question). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 26 19:18:30 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Aug 2015 19:18:30 -0000 Subject: [GHC] #10797: Kind-level functional dependencies are not resolved properly In-Reply-To: <046.e5566984a246d66127e6e59197588043@haskell.org> References: <046.e5566984a246d66127e6e59197588043@haskell.org> Message-ID: <061.da5317e869ac6bcc17f33755da7a5c1f@haskell.org> #10797: Kind-level functional dependencies are not resolved properly -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by danilo2): Here is even simpler example: {{{ class BaseType (a :: k) (b :: l) | a -> b, k -> l where baseType :: Proxy a -> Proxy b instance {-# OVERLAPPABLE #-} BaseType (( (a :: l -> x) (t :: l)) ) (a :: l -> x) where baseType _ = Proxy }}} error: {{{ Illegal instance declaration for ?BaseType (a t) a? The liberal coverage condition fails in class ?BaseType? for functional dependency: ?k -> l? Reason: lhs type ?x? does not determine rhs type ?l -> x? In the instance declaration for ?BaseType (((a :: l -> x) (t :: l))) (a :: l -> x)? }}} where it seems again, that GHC cannot infer funded between {{{l -> x}}} and {{{l -> x}}}, "thinking" that LHS of funded is {{{x}}} instead of {{{l -> x}}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 26 19:57:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Aug 2015 19:57:31 -0000 Subject: [GHC] #10797: Kind-level functional dependencies are not resolved properly In-Reply-To: <046.e5566984a246d66127e6e59197588043@haskell.org> References: <046.e5566984a246d66127e6e59197588043@haskell.org> Message-ID: <061.76b17ad9c5b4b6ee2f90e0194d7a4d9b@haskell.org> #10797: Kind-level functional dependencies are not resolved properly -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by danilo2): And one more additional fact. We can implement what I want creating some boilerplate. I'm sure there should be way to avoid it (without using TemplateHaskell): {{{ class BaseType a b | a -> b where baseType :: a -> b instance {-# OVERLAPPABLE #-} out ~ (Proxy a) => BaseType (Proxy a) out instance {-# OVERLAPPABLE #-} out ~ (Proxy a) => BaseType (Proxy (a t1)) out instance {-# OVERLAPPABLE #-} out ~ (Proxy a) => BaseType (Proxy (a t1 t2)) out instance {-# OVERLAPPABLE #-} out ~ (Proxy a) => BaseType (Proxy (a t1 t2 t3)) out instance {-# OVERLAPPABLE #-} out ~ (Proxy a) => BaseType (Proxy (a t1 t2 t3 t4)) out instance {-# OVERLAPPABLE #-} out ~ (Proxy a) => BaseType (Proxy (a t1 t2 t3 t4 t5)) out ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 26 21:41:02 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Aug 2015 21:41:02 -0000 Subject: [GHC] #10797: Kind-level functional dependencies are not resolved properly In-Reply-To: <046.e5566984a246d66127e6e59197588043@haskell.org> References: <046.e5566984a246d66127e6e59197588043@haskell.org> Message-ID: <061.5735e7545fc9ba748fdfb0843a3d99d8@haskell.org> #10797: Kind-level functional dependencies are not resolved properly -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: Let's take your simpler example: {{{ class BaseType @k @l (a :: k) (b :: l) | a -> b, k -> l where ... }}} I have added in the (invisible in source code) kind parameters to `BaseType`. Now the instance: {{{ instance BaseType @x @(y->x) (( (v :: y -> x) (t :: y)) ) (v :: y -> x) where ... }}} Again I have added in the invisible kind parameters, and I've changed variable names to avod name clashes. In this instance we see the following instantiation of the class variables: {{{ Class variable Instantiated by k x l y->x a::k ((v::y->x) (t::y)) :: x b::l t :: y }}} Now look at the fundeps. * `a -> b`: Does the type that instantiates `a::k` (namely `((v::y->x) (t::y)) :: x`) determine the type that instantiates `b::l` (namely `t::y`)? Yes, both `t` and `y` appear in the lhs type. * `k->l`: Does the kind that instantiates `k` (namely `x`) determin the kind that instantiates `l` (namely `y->x`)? Obviously not. So the instance is rejected. If you omit the fundep `k->l` you'll be fine, and indeed all your examples work then. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 26 21:51:52 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Aug 2015 21:51:52 -0000 Subject: [GHC] #10661: Regression: hp2ps reports `integer unexpected` on new style package keys In-Reply-To: <045.9c4a37e2fa0ae7c34e598ac5ff3e0cab@haskell.org> References: <045.9c4a37e2fa0ae7c34e598ac5ff3e0cab@haskell.org> Message-ID: <060.7d303f360841d586415eca2481688ff6@haskell.org> #10661: Regression: hp2ps reports `integer unexpected` on new style package keys -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.12.1 Component: Profiling | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | concurrent/prog002/concprog002 Blocked By: | Blocking: Related Tickets: #10550 | Differential Revisions: Phab:D1175 -------------------------------------+------------------------------------- Comment (by thomie): Ok, that would explain it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 26 22:55:18 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Aug 2015 22:55:18 -0000 Subject: [GHC] #10791: Add a --disable-large-memory-space configure option In-Reply-To: <044.dad24b52dfdb3ab9a4e1b09182a3fa05@haskell.org> References: <044.dad24b52dfdb3ab9a4e1b09182a3fa05@haskell.org> Message-ID: <059.371038ba4b222c75834eb7a9509d7380@haskell.org> #10791: Add a --disable-large-memory-space configure option -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: closed Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1170 -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 26 23:43:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Aug 2015 23:43:08 -0000 Subject: [GHC] #9257: CC_CLANG_BACKEND not reconfigured during bindist install In-Reply-To: <050.30f8cd90b97558f93f1173aa6607ce01@haskell.org> References: <050.30f8cd90b97558f93f1173aa6607ce01@haskell.org> Message-ID: <065.12194e78e5b10f6826ce31377b380d8c@haskell.org> #9257: CC_CLANG_BACKEND not reconfigured during bindist install -------------------------------------+------------------------------------- Reporter: MtnViewMark | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Resolution: fixed | Keywords: clang Operating System: MacOS X | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #8683 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * related: => #8683 Comment: Thanks to a patch by carter in #8683, the bindist configure script now figures out which C preprocessor to use, and which flags to pass it. Those settings are written to the `settings` file. I just tested all this with HEAD, and it seems to work fine. Please reopen if something is still not working. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 26 23:50:04 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Aug 2015 23:50:04 -0000 Subject: [GHC] #9932: GHC fails to build when cross compiling for mingw with the message "Threads not supported" In-Reply-To: <049.e487d99eeb784ebf45e20f30dbd986d2@haskell.org> References: <049.e487d99eeb784ebf45e20f30dbd986d2@haskell.org> Message-ID: <064.352db5c2729b4bbdabdbfa69ef313e21@haskell.org> #9932: GHC fails to build when cross compiling for mingw with the message "Threads not supported" -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.4 Resolution: | Keywords: Cross | compiling Operating System: Linux | Architecture: x86 Type of failure: Building GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: #9524 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * related: 9542 => #9524 Old description: > I'm trying to build a mingw32 cross compiler. > I configured with `./configure --target=x86_64-x64-mingw32`, then I built > with `make -j 1`. > The build then fails with the message ` # error "Threads not supported"` > followed by some other errors. (The last part of the make log is > attached) > > To bypass #9542, I deleted the following lines from utils/hsc2hs/Main.hs: > > {{{ > #if defined(__GLASGOW_HASKELL__) && !defined(BUILD_NHC) > #include "../../includes/ghcconfig.h" > #endif > }}} New description: I'm trying to build a mingw32 cross compiler. I configured with `./configure --target=x86_64-x64-mingw32`, then I built with `make -j 1`. The build then fails with the message ` # error "Threads not supported"` followed by some other errors. (The last part of the make log is attached) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 26 23:55:12 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Aug 2015 23:55:12 -0000 Subject: [GHC] #3354: binaries built with GHC on Mac OS X 10.5 (Leopard) do not work on 10.4 (Tiger) In-Reply-To: <047.37055053b1160c638a5374c844089d6a@haskell.org> References: <047.37055053b1160c638a5374c844089d6a@haskell.org> Message-ID: <062.4ff808f056596158e514f5219f281843@haskell.org> #3354: binaries built with GHC on Mac OS X 10.5 (Leopard) do not work on 10.4 (Tiger) -------------------------------------+------------------------------------- Reporter: bkomuves | Owner: Type: bug | Status: closed Priority: normal | Milestone: ? Component: Build System | Version: 6.10.1 Resolution: wontfix | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * failure: => None/Unknown * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 00:08:37 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 00:08:37 -0000 Subject: [GHC] #7152: Add flag to configure that skips overwriting of symlinks on install In-Reply-To: <044.af90b81c38ba7c31604bedf0b5844194@haskell.org> References: <044.af90b81c38ba7c31604bedf0b5844194@haskell.org> Message-ID: <059.c113399eaa9c40e32259e8635f5a5979@haskell.org> #7152: Add flag to configure that skips overwriting of symlinks on install -------------------------------------+------------------------------------- Reporter: tibbe | Owner: | thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): See also this thread: https://mail.haskell.org/pipermail/glasgow-haskell- users/2015-July/026020.html "simultaneous ghc versions", which [http://www.haskell.org/pipermail/glasgow-haskell-users/ concluded] with: > > > Come to think of it, shouldn't ghc include this, instead of > > > everyone creating their own shell scripts by hand? > > I don't think so. This is usually done in the userland -- at least in > > GNU+Linux distributions. > More to the point, various distribution methods already include such things > (e.g. NixOS, Debian's alternatives system, MacPorts' "port select") plus > there are various mechanisms for implementing this on an ad-hoc basis (GNU > stow, environment modules, etc.). Downstream packages implementing their > own versions of this except speicifically on an opt-in basis (e.g. > configure option) tend to interfere with these and complicate inclusion > into existing package systems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 00:21:40 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 00:21:40 -0000 Subject: [GHC] #9315: Weird change in allocation numbers of T9203 In-Reply-To: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> References: <046.bf594362f9f69cd1846ba2527a543cbf@haskell.org> Message-ID: <061.f0022272073833b0c7e0c71da02e2d89@haskell.org> #9315: Weird change in allocation numbers of T9203 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8096 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * related: => #8096 Comment: See also ezyang's proposal for a fudge-factor for performance tests run on non-validate builds: #8096. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 00:25:56 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 00:25:56 -0000 Subject: [GHC] #8096: Add fudge-factor for performance tests run on non-validate builds In-Reply-To: <045.2bbaf3015957b89cf5821517eafcc5cd@haskell.org> References: <045.2bbaf3015957b89cf5821517eafcc5cd@haskell.org> Message-ID: <060.ea3e19bbb47cf0d32eb2af49099f7d35@haskell.org> #8096: Add fudge-factor for performance tests run on non-validate builds -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9315 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * related: => #9315 Comment: See ticket:9315#comment:24 for a proposal to only run performance tests when validating with release settings (-O2). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 01:20:50 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 01:20:50 -0000 Subject: [GHC] #10032: binary distributions not working --with-system-libffi In-Reply-To: <046.5141c8639bf6744efaba9be368d440ce@haskell.org> References: <046.5141c8639bf6744efaba9be368d440ce@haskell.org> Message-ID: <061.99b8ffb58ba571a8c07667b5c33c6b33@haskell.org> #10032: binary distributions not working --with-system-libffi -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5743 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * related: => #5743 Comment: For reference, the configure option `--with-system-libffi` was added in #5743. Using `./configure --with-system-libffi` in a bindist, you should see the following warning: {{{ WARNING: unrecognized options: --with-system-libffi }}} kgardas: do you want to keep this open as a feature request, or is it sufficient for you to be able to build GHC `--with-system-libffi`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 06:03:54 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 06:03:54 -0000 Subject: [GHC] #8947: Depending on hint/ghc API fixes the binary version I can use In-Reply-To: <042.0b84808e71990b7e49b9c7a55ecf27f4@haskell.org> References: <042.0b84808e71990b7e49b9c7a55ecf27f4@haskell.org> Message-ID: <057.d3c7506ba2d5454de6b93954170515cc@haskell.org> #8947: Depending on hint/ghc API fixes the binary version I can use -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.6.3 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): Technically this is this Cabal bug: the required feature is for Cabal to understand how some dependencies of a package should be considered "private" and thus have an extra degree of freedom when dependency solving. GHC already has the capability to link against multiple versions of binary; the problem is convincing Cabal that this is kosher. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 06:05:20 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 06:05:20 -0000 Subject: [GHC] #10714: After implementing new installed package ID (hash of sdist), get rid of package keys In-Reply-To: <045.13deae8316589a147d8e83f0a90ec4d1@haskell.org> References: <045.13deae8316589a147d8e83f0a90ec4d1@haskell.org> Message-ID: <060.4dbb605acbd946a8c76f18ace2662afd@haskell.org> #10714: After implementing new installed package ID (hash of sdist), get rid of package keys -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.10.2 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): Another point: when Backpack is back in the picture, `UnitKey` only equals `InstalledPackageId` if the package in question is a non-Backpack package (installed package ID is per package, but a package can have multiple units.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 06:29:52 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 06:29:52 -0000 Subject: [GHC] #10798: Signatures with only types should not be included in unit keys Message-ID: <045.a9d0a60676134e87bb6bcdfe70d2a8f5@haskell.org> #10798: Signatures with only types should not be included in unit keys -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Priority: normal | Milestone: ? Component: Package | Version: 7.11 system | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Suppose we want to modularize the dependence on `p` in this program: {{{ unit p where module A where data T = T mkT = T unit q where include p module B where import A bar = mkT }}} The obvious signature to write for `A` is: {{{ signature A where data T mkT :: T }}} But this presupposes an implementation of `A` which exports `T`. But `B` doesn't use any export of `T`, and an equally valid implementation would be if `T` was defined in some `Types` module and then imported here. But suppose we change our signature to be: {{{ signature A.Types where data T signature A where import A.Types mkT :: T }}} This is maximally general, but requires that the module which exports `T` be named `A.Types`. If someone puts the type anywhere else, we have to rename the signature to the real place it was defined, or make a dummy implementation module which reexports the type in question. Now there is a curious thing, which is that the choice of module we use to fill these extra signature modules currently influences the type identity of anything else in the unit. But we never rely on any code from these signatures: if I make two distinct dummy modules to set `T` to the same type, this really shouldn't have any impact (at all!) on the code generated. So, my suggestion is that if a signature contains only types (perhaps they could be named something else, like `tysignature`), they should not count towards the calculation of a unit key. This means that a user can freely create dummy modules to fill in these types when they are instantiating; all that is being done is helping Backpack figure out what the identities of types are. (If we wanted to be fancy, Backpack could even look inside type signatures to determine some types, but let's not go there for now.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 07:01:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 07:01:48 -0000 Subject: [GHC] #10032: binary distributions not working --with-system-libffi In-Reply-To: <046.5141c8639bf6744efaba9be368d440ce@haskell.org> References: <046.5141c8639bf6744efaba9be368d440ce@haskell.org> Message-ID: <061.a86a5a21dcc2d0a96d3b047156f4785f@haskell.org> #10032: binary distributions not working --with-system-libffi -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5743 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by kgardas): thomie: I'm afraid that due to GHC support for shared libraries and due to OSes shipping their own libffi we kind of need support for system libffi also in binary distribution. I've hit this on Solaris, but the situation on OpenBSD is the same (don't know about Linux): sometimes you can end with the target application binary which is linked against both system and ghc supplied libffi -- IMHO very unlucky situation so I would appreciate kept this open if this does not hurt that much. Thanks! Karel -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 11:17:51 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 11:17:51 -0000 Subject: [GHC] #4879: Deprecate exports In-Reply-To: <049.ea1fa273b308c2a35269907288b50645@haskell.org> References: <049.ea1fa273b308c2a35269907288b50645@haskell.org> Message-ID: <064.1361f9eb12e31445926bcbe5c7f01872@haskell.org> #4879: Deprecate exports -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: feature request | Status: infoneeded Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: deprecate | warning Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10071 #2119 | Differential Revisions: Phab:D638 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: It would be nice to see this for 7.12. However, in order for that to happen we should have a specification. The patch here is nice, but I agree with Simon that we really want to have a single easy-to-follow description of how this feature is supposed to work. Bas, perhaps you could take this up? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 11:40:45 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 11:40:45 -0000 Subject: [GHC] #9447: Add support for resizing `MutableByteArray#`s In-Reply-To: <042.51867a8225b599fb4ff13dcceb122580@haskell.org> References: <042.51867a8225b599fb4ff13dcceb122580@haskell.org> Message-ID: <057.d3dd6452c02941d2bfba90366177f342@haskell.org> #9447: Add support for resizing `MutableByteArray#`s -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D133, | Phab:D1139 -------------------------------------+------------------------------------- Comment (by bgamari): hvr, I discussed this briefly with Simon Marlow in the meeting last week and he indicated that it may not be too tricky to implement efficient growing of ByteArrays. Perhaps you'd like to discuss this with him (assuming you still believe this is a worthwhile optimization)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 11:41:16 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 11:41:16 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.179cedc2ba91221c2700b88b91fbd0f2@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: 8317 Related Tickets: #1498 | Differential Revisions: Phab:D343 -------------------------------------+------------------------------------- Comment (by bgamari): Reid, any progress here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 11:45:18 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 11:45:18 -0000 Subject: [GHC] #4505: Segmentation fault on long input (list of pairs) In-Reply-To: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> References: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> Message-ID: <061.65870652df62367ec64ef509880be98b@haskell.org> #4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: | Segmentation fault, segfault, long | input Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: 4258 | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Simonmar, what do we want to do about this? IMHO we should at least reinstate the compile-time warning before 7.12. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 12:23:45 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 12:23:45 -0000 Subject: [GHC] #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` In-Reply-To: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> References: <042.89bb0eec284b44a45a7b0586c22bb7a4@haskell.org> Message-ID: <057.b3769878c7bd071b896b9f153e396e9c@haskell.org> #8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` -------------------------------------+------------------------------------- Reporter: hvr | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Core Libraries | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | simplCore/should_compile/T8832 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * owner: ekmett => bgamari Comment: I discussed this with Simon during out GHC meeting and we agreed that the best solution here would be to add a `PrelRule` covering `bit`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 12:55:38 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 12:55:38 -0000 Subject: [GHC] #4505: Segmentation fault on long input (list of pairs) In-Reply-To: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> References: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> Message-ID: <061.eb0840cdf85e667713ddeb66f60a155b@haskell.org> #4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: | Segmentation fault, segfault, long | input Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: 4258 | Blocking: Related Tickets: | Differential Revisions: D1180 -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => D1180 Comment: I've opened Phab:D1180 reintroducing the compile-time check. It would however, be nice to know what would need to happen to fix the RTS. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 12:56:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 12:56:08 -0000 Subject: [GHC] #4505: Segmentation fault on long input (list of pairs) In-Reply-To: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> References: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> Message-ID: <061.8238b1bea3e5513b4ca927d13cd9ae4a@haskell.org> #4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: | Segmentation fault, segfault, long | input Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: 4258 | Blocking: Related Tickets: | Differential Revisions: D1180 -------------------------------------+------------------------------------- Changes (by bgamari): * owner: simonmar => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 13:20:43 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 13:20:43 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.788c95f33f6e14ad9edee50bf122e04f@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: 5321 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari Comment: I'll try to have a look at this. Looks like a nice area for improvement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 13:37:07 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 13:37:07 -0000 Subject: [GHC] #10799: "I found a duplicate definition for symbol: __x86.get_pc_thunk.bx" in package network Message-ID: <047.a777ede82e63f4bc5c43944be8461ea4@haskell.org> #10799: "I found a duplicate definition for symbol: __x86.get_pc_thunk.bx" in package network -------------------------------------+------------------------------------- Reporter: blueonyx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #9657 Differential Revisions: | -------------------------------------+------------------------------------- hi, i get this panic! using hint to interpret code which uses the network package (on 32bit ubuntu): {{{ GHC runtime linker: fatal error: I found a duplicate definition for symbol __i686.get_pc_thunk.bx whilst processing object file /home/mechgen/get_pc_thunk.bx/.cabal-sandbox/lib/i386-linux- ghc-7.10.2/network-2.6.2.1-F6mK9sCIw3M5SbZMt2lUQE/libHSnetwork-2.6.2.1-F6mK9sCIw3M5SbZMt2lUQE.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. Left (GhcException "panic! (the 'impossible' happened)\n (GHC version 7.10.2 for i386-unknown-linux):\n\tloadArchive \"/home/mechgen/get_pc_thunk.bx/.cabal-sandbox/lib/i386-linux- ghc-7.10.2/network-2.6.2.1-F6mK9sCIw3M5SbZMt2lUQE/libHSnetwork-2.6.2.1-F6mK9sCIw3M5SbZMt2lUQE.a\": failed\n\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\n") }}} the problem also arises when the interpreted module imports a module which imports network, so it doesn't have to import network directly. also "it worked before". i can't really remember the previous working versions, but it must have been something like ghc 7.6.3 and haskell- platform 2013.2.0.0. the related ticket mentioned building without -fPIC, but i can't find it in network's cabal file. more info: {{{ $ uname -a Linux mechgen 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri Jan 25 17:15:33 UTC 2013 i686 i686 i386 GNU/Linux $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.2 $ cabal --version cabal-install version 1.22.6.0 using version 1.22.4.0 of the Cabal library }}} to reproduce: {{{ $ mv ~/Compile.hs ~/DummyImportingNetwork.hs . $ cabal sandbox init $ cabal install network==2.6.2.1 hint==0.4.2.3 $ cabal exec -- ghc --make -o compile Compile.hs $ PATH=.:$PATH cabal exec compile }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 13:45:55 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 13:45:55 -0000 Subject: [GHC] #10172: Cross-platform sed In-Reply-To: <045.1be076a91930fb4fb7093c910a217d5c@haskell.org> References: <045.1be076a91930fb4fb7093c910a217d5c@haskell.org> Message-ID: <060.b6de20592e69c5ae3229343c3a7d6183@haskell.org> #10172: Cross-platform sed -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Solaris | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Can't we just make life easy for the majority of developers, and require GNU tools. There are already so many things to keep in mind when submitting a patch to GHC, why make it even harder? What's the problem with installing GNU tools on Solaris? It would also free up time to fix *actual* problems on Solaris (there are plenty, judging by the failing tests on the nightly builders), not these silly compatibility issues. For reference, in `configure.ac`: {{{ dnl ** Find the path to sed AC_PATH_PROGS(SedCmd,gsed sed,sed) dnl ** check for time command AC_PATH_PROG(TimeCmd,time) dnl ** check for tar dnl if GNU tar is named gtar, look for it first. AC_PATH_PROGS(TarCmd,gnutar gtar tar,tar) dnl ** check for patch dnl if GNU patch is named gpatch, look for it first AC_PATH_PROGS(PatchCmd,gpatch patch, patch) }}} Also: {{{ commit 22f78dd456cdf6d6c123556e3f715d008ecd86cd Author: Ian Lynagh <> Date: Tue Dec 1 13:07:41 2009 +0000 Look for sed as gsed first Solaris's sed apparently doesn't understand [:space:] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 13:46:57 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 13:46:57 -0000 Subject: [GHC] #10799: "I found a duplicate definition for symbol: __x86.get_pc_thunk.bx" in package network In-Reply-To: <047.a777ede82e63f4bc5c43944be8461ea4@haskell.org> References: <047.a777ede82e63f4bc5c43944be8461ea4@haskell.org> Message-ID: <062.c1b228a54a052abe4198009e2e28a307@haskell.org> #10799: "I found a duplicate definition for symbol: __x86.get_pc_thunk.bx" in package network -------------------------------------+------------------------------------- Reporter: blueonyx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9657 | Differential Revisions: -------------------------------------+------------------------------------- Description changed by blueonyx: Old description: > hi, i get this panic! using hint to interpret code which uses the > network package (on 32bit ubuntu): > > {{{ > GHC runtime linker: fatal error: I found a duplicate definition for > symbol > __i686.get_pc_thunk.bx > whilst processing object file > /home/mechgen/get_pc_thunk.bx/.cabal-sandbox/lib/i386-linux- > ghc-7.10.2/network-2.6.2.1-F6mK9sCIw3M5SbZMt2lUQE/libHSnetwork-2.6.2.1-F6mK9sCIw3M5SbZMt2lUQE.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. > Left (GhcException "panic! (the 'impossible' happened)\n (GHC version > 7.10.2 for i386-unknown-linux):\n\tloadArchive > \"/home/mechgen/get_pc_thunk.bx/.cabal-sandbox/lib/i386-linux- > ghc-7.10.2/network-2.6.2.1-F6mK9sCIw3M5SbZMt2lUQE/libHSnetwork-2.6.2.1-F6mK9sCIw3M5SbZMt2lUQE.a\": > failed\n\nPlease report this as a GHC bug: > http://www.haskell.org/ghc/reportabug\n") > }}} > > the problem also arises when the interpreted module imports a module > which imports network, so it doesn't have to import network directly. > > also "it worked before". i can't really remember the previous working > versions, but it must have been something like ghc 7.6.3 and haskell- > platform 2013.2.0.0. > > the related ticket mentioned building without -fPIC, but i can't find it > in network's cabal file. > > more info: > {{{ > $ uname -a > Linux mechgen 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri Jan 25 > 17:15:33 UTC 2013 i686 i686 i386 GNU/Linux > $ ghc --version > The Glorious Glasgow Haskell Compilation System, version 7.10.2 > $ cabal --version > cabal-install version 1.22.6.0 > using version 1.22.4.0 of the Cabal library > }}} > > to reproduce: > > {{{ > $ mv ~/Compile.hs ~/DummyImportingNetwork.hs . > $ cabal sandbox init > $ cabal install network==2.6.2.1 hint==0.4.2.3 > $ cabal exec -- ghc --make -o compile Compile.hs > $ PATH=.:$PATH cabal exec compile > }}} New description: hi, i get this panic! using hint to interpret code which uses the network package (on 32bit ubuntu): {{{ GHC runtime linker: fatal error: I found a duplicate definition for symbol __i686.get_pc_thunk.bx whilst processing object file /home/mechgen/get_pc_thunk.bx/.cabal-sandbox/lib/i386-linux- ghc-7.10.2/network-2.6.2.1-F6mK9sCIw3M5SbZMt2lUQE/libHSnetwork-2.6.2.1-F6mK9sCIw3M5SbZMt2lUQE.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. Left (GhcException "panic! (the 'impossible' happened)\n (GHC version 7.10.2 for i386-unknown-linux):\n\tloadArchive \"/home/mechgen/get_pc_thunk.bx/.cabal-sandbox/lib/i386-linux- ghc-7.10.2/network-2.6.2.1-F6mK9sCIw3M5SbZMt2lUQE/libHSnetwork-2.6.2.1-F6mK9sCIw3M5SbZMt2lUQE.a\": failed\n\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\n") }}} the problem also arises when the interpreted module imports a module which imports network, so it doesn't have to import network directly. also "it worked before". i can't really remember the previous working versions, but it must have been something like ghc 7.6.3 and haskell- platform 2013.2.0.0. the related ticket mentioned building without -fPIC, but i can't find it in network's cabal file. more info: {{{ $ uname -a Linux mechgen 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri Jan 25 17:15:33 UTC 2013 i686 i686 i386 GNU/Linux $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.2 $ cabal --version cabal-install version 1.22.6.0 using version 1.22.4.0 of the Cabal library }}} to reproduce: {{{ cat < Compile.hs module Main where import Control.Exception (bracket) import System.IO (openTempFile, hClose, hPutStr) import System.Directory (removeFile) import Language.Haskell.Interpreter hiding (reset, get) withTempFile :: FilePath -> FilePath -> String -> (FilePath -> IO a) -> IO a withTempFile tempDir name' body action = do (fp,h) <- openTempFile tempDir (name' ++ ".hs") hPutStr h body hClose h bracket (return fp) (\fp' -> removeFile fp') action compile :: IO (Either InterpreterError Int) compile = do let tempDir = "." let name' = "DummyImportingNetwork" body <- readFile $ name' ++ ".hs" withTempFile tempDir name' body $ \fp -> do runInterpreter $ do set [installedModulesInScope := True] loadModules [fp] setTopLevelModules [name'] interpret ("foobar") infer main = compile >>= print EOF cat < DummyImportingNetwork.hs module DummyImportingNetwork where -- this breaks everything import Network.Socket -- this just has to typecheck foobar :: Int foobar = 23 EOF cabal sandbox init cabal install network==2.6.2.1 hint==0.4.2.3 cabal exec -- ghc --make -o compile Compile.hs PATH=.:$PATH cabal exec compile }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 13:48:29 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 13:48:29 -0000 Subject: [GHC] #10800: vector-0.11 Message-ID: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> #10800: vector-0.11 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- vector-0.11 takes substantially longer to compile with 7.10 than 7.8 Unfortunately the issue appears to be in generated code. Lacking time right now so I'm just going to drop the IRC log here, Compile log: https://travis-ci.org/haskell/vector/builds/56179052 {{{ * hvr thought some compile-time improvements landed in 7.10.2 I don't think it uses sufficiently less memory to prevent it from using all memory on travis and failing. Which is why it suddenly went from 8 minutes to 35. Although it's also significantly worse even when you have enough memory. hvr: 7.8.4 takes 4m40s, 7.10.2 takes 16m40s. i7 4770, 32GB RAM. vector 0.11 branch. It's not as bad in the 0.10 branch. It uses like 60% more memory, too. Maybe more. It's really just one or two files in the test suite that take all the time/memory. dolio: does vector do some aggressive INLINEing? Well, yes. more in 0.11 than in 0.10? It does more stuff in 0.11, yes. vector 0.11 has this new chunked streaming abstraction IIRC there's a generic one though iirc 0.11 introduced the generalized stream fusion, so there's like three different things going on that specialization has to select one of. Instead of just one thing like in 0.10. Anyhow, the problem file(s) generate a bunch of tests using template Haskell, so they're pretty opaque. I'm pretty sure it's the generated code that's the problem, though. Not the template haskell that generates it. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 13:49:27 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 13:49:27 -0000 Subject: [GHC] #10800: vector-0.11 compile time increased substantially with 7.10.1 (was: vector-0.11) In-Reply-To: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> References: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> Message-ID: <061.7cd47d8156eb9af003268a708c66afd6@haskell.org> #10800: vector-0.11 compile time increased substantially with 7.10.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 14:36:16 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 14:36:16 -0000 Subject: [GHC] #10800: vector-0.11 compile time increased substantially with 7.10.1 In-Reply-To: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> References: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> Message-ID: <061.66820c92b5484ca1cf99149ed17eab83@haskell.org> #10800: vector-0.11 compile time increased substantially with 7.10.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 7.12.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * priority: normal => highest Comment: Let's be sure to look at this; increasing priority. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 14:49:37 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 14:49:37 -0000 Subject: [GHC] #10172: Cross-platform sed In-Reply-To: <045.1be076a91930fb4fb7093c910a217d5c@haskell.org> References: <045.1be076a91930fb4fb7093c910a217d5c@haskell.org> Message-ID: <060.3482cdbb0825871df94f6d95a533103e@haskell.org> #10172: Cross-platform sed -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Solaris | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by kgardas): thomie, honestly I really like I can compile GHC and use canonical Single- Unix Specification version 3 tools for it minus GNU make which is really non-replacable at least for now. Just see https://www.freebsd.org/cgi/man.cgi?query=standards&apropos=0&sektion=0&manpath=SunOS+5.10&arch=default&format=html -- I'm using configuration to set the OS to POSIX.1-2001, SUSv3 level. Anyway, if devs decide let's go with GNU tools (patch/diff/sed) together with GNU make I will not strike against this, don't have energy for it. The question is ROI of such change, do we need it *now*? I don't think so, Solaris builders are running fine on current HEAD. How often do we need to tweak sed invocation in current build system? 4x per calendar year? So let's decide once this thing is again broken not now when everything is working fine. Side note: shouldn't we already use shake for building GHC? Not complaining, but from this spring I've got an impression that shake is on the way to GHC and that it would solve several issues I also do have with build system myself (too low usage of available cores). If this all still applies, then I would suggest not to touch current make-based system, keep it just working with as low energy as possible and concentrate on other GHC important tasks... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 14:50:57 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 14:50:57 -0000 Subject: [GHC] #10793: Incorrect blocked on MVar detection In-Reply-To: <051.7658851bb71506c4b1bae1ee7211ff06@haskell.org> References: <051.7658851bb71506c4b1bae1ee7211ff06@haskell.org> Message-ID: <066.3d978c1d1ad90b928f9ca857407b877a@haskell.org> #10793: Incorrect blocked on MVar detection -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: wontfix | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => wontfix Comment: This is working as intended. At the time the forked thread is deadlocked, the main thread is also deadlocked (the dependency between them is not visible to the GC). If you want to keep the main thread alive manually, you can do this: {{{ newStablePtr =<< myThreadId }}} from the main thread. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 14:58:41 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 14:58:41 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.9ae7ed628c9400b09610185610ede53a@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: 5321 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): I got caught in this morass some time ago, but my comment:1 is out-of-date at this point: I am well acquainted with how all this works in the solver these days. So I'm happy to help out, but I don't have the bandwidth now to take the lead here. Thanks, Ben! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 15:25:36 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 15:25:36 -0000 Subject: [GHC] #10445: Wrong stack space size when using -Ksize In-Reply-To: <042.794c5bde83bb1d57f2fc1adc9766262f@haskell.org> References: <042.794c5bde83bb1d57f2fc1adc9766262f@haskell.org> Message-ID: <057.e4132f5b7dd3f367611ebfe02cc9733d@haskell.org> #10445: Wrong stack space size when using -Ksize -------------------------------------+------------------------------------- Reporter: asr | Owner: archblob Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D938, | Phab:D961 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: This seems to have been merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 15:31:10 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 15:31:10 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.c2b7252c28672c4992a2cfa3479c1187@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, | deepseq, evaluate, exceptions Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #5129 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * related: => #5129 Comment: See also: https://ghc.haskell.org/trac/ghc/ticket/5129#comment:17. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 15:41:22 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 15:41:22 -0000 Subject: [GHC] #9334: Implement "instance chains" In-Reply-To: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> References: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> Message-ID: <062.8e8d39165e9a0d74a610c7948be183ef@haskell.org> #9334: Implement "instance chains" -------------------------------------+------------------------------------- Reporter: diatchki | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jstolarek (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 15:59:56 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 15:59:56 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.abbd8526a1bd4d3ad3aedb0ad5d8c9be@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by Ansible): Just wanted to point out that on raspberry pi 2 with debian jessie, ghc and ghci are both broken. I tried the ghc binary from the ghc site, and it fails with the "Planet" test (from the top of this thread) in ghci, and in compiled code it fails "hello world". So its pretty much a show stopper for ARM. {{{ GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help Prelude> data Planet = Mercury | Venus deriving Eq Prelude> Mercury == Mercury Illegal instruction bburdette at jessie-rpi:~$ And my hello world program: main = do putStrLn "hello" The results: bburdette at jessie-rpi:~$ ghc hello.hs [1 of 1] Compiling Main ( hello.hs, hello.o ) Linking hello ... bburdette at jessie-rpi:~$ ls bin ghc-7.10.2-arm-unknown-linux.tar.xz hello.hi hello.o code hello hello.hs bburdette at jessie-rpi:~$ ./hello Illegal instruction bburdette at jessie-rpi:~$ ghc -O2 hello.hs bburdette at jessie-rpi:~$ ./hello Illegal instruction bburdette at jessie-rpi:~$ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 16:38:20 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 16:38:20 -0000 Subject: [GHC] #8582: Record syntax for pattern synonyms In-Reply-To: <045.711f298e5aa28ce184df85985d614bd2@haskell.org> References: <045.711f298e5aa28ce184df85985d614bd2@haskell.org> Message-ID: <060.4f89acd3b1167e17b5e1a19bcc994a76@haskell.org> #8582: Record syntax for pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: mpickering Type: feature request | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 5144 | Blocking: Related Tickets: | Differential Revisions: Phab:D1152 -------------------------------------+------------------------------------- Changes (by simonpj): * priority: normal => high * milestone: => 7.12.1 Comment: Matthew says he thinks this'll be ready for 7.12 so I'll milestone it as such. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 19:35:55 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 19:35:55 -0000 Subject: [GHC] #10796: Illegal data constructor name: `fromList' ... When splicing a TH expression In-Reply-To: <045.67153471687796395f900337ba5220e7@haskell.org> References: <045.67153471687796395f900337ba5220e7@haskell.org> Message-ID: <060.b830e20545f51edc1118e9cb3f2d6b09@haskell.org> #10796: Illegal data constructor name: `fromList' ... When splicing a TH expression -------------------------------------+------------------------------------- Reporter: erisco | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: newcomer Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: => newcomer * milestone: => 7.12.1 Comment: Milestoning this so that I return to it when dispatching a bunch of TH tickets this fall. But this would be easy for just about anyone to tackle. Just update `dataToQa`! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 19:42:26 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 19:42:26 -0000 Subject: [GHC] #10789: Notify user when a kind mismatch holds up a type family reduction In-Reply-To: <047.282dd8bb976bc76373d556a5e980ac6e@haskell.org> References: <047.282dd8bb976bc76373d556a5e980ac6e@haskell.org> Message-ID: <062.f3f2508a5b71a01dea5ad01ffe725a84@haskell.org> #10789: Notify user when a kind mismatch holds up a type family reduction -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: => newcomer * milestone: => 7.12.1 Comment: A little coding in `TcErrors` should do it. Happy to advise someone who wants to take this on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 19:47:05 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 19:47:05 -0000 Subject: [GHC] #10776: DataKinds promotion of String -> Symbol and Natural -> Nat In-Reply-To: <048.67491201a04ddd5c5f8addf4fce96596@haskell.org> References: <048.67491201a04ddd5c5f8addf4fce96596@haskell.org> Message-ID: <063.35fd66dea17a4f7f837b1878e4146228@haskell.org> #10776: DataKinds promotion of String -> Symbol and Natural -> Nat -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: DataKinds Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Combining `Natural` and `Nat` seems straightforward. But `Symbol` and `String` are different: the former is not a list of characters. `Symbol` is much more like a promoted `Text` than a promoted `String`. And we might want the kind `String` to mean a type-level list of type-level characters someday. Even better than making progress on these small issues is to step back and come up with a plan for type-level literals of all stripes (floating-point numbers, characters, a promoted `Num` class of some sort?). I'm worried that small forays into this space will dig us into a local minimum from which we can't escape. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 22:05:18 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 22:05:18 -0000 Subject: [GHC] #10801: ghc returns ExitFailure (-4) when compiling some projects on ARM Message-ID: <046.137bdeead56cfd325f05891a55ecd378@haskell.org> #10801: ghc returns ExitFailure (-4) when compiling some projects on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: Compile-time Test Case: compile a | crash big web project | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I'm trying to get either yesod or scotty to build on my raspberry pi 2, which is running arch. Arch sports the newest working compiler for ghc, 7.8.2. Unfortunately llvm on arch is TOO new, and one must downgrade llvm, and the llvm downgrade packages are not available anywhere officially. I, however, happen to have these packages. These are for llvm 3.4.2-1.1. At any rate, I find I'm at an impasse with both Yesod and with Scotty. Sample output is attached. There's quite a bit of success, having compiled a lot of libraries, but it fails at the end. I thought it might be a lack of memory, so I gave it a try with a 1G swapfile as well, but that didn't help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 22:06:32 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 22:06:32 -0000 Subject: [GHC] #10801: ghc returns ExitFailure (-4) when compiling some projects on ARM In-Reply-To: <046.137bdeead56cfd325f05891a55ecd378@haskell.org> References: <046.137bdeead56cfd325f05891a55ecd378@haskell.org> Message-ID: <061.8937fe011fd24a2a64fc3bfcfc8865c7@haskell.org> #10801: ghc returns ExitFailure (-4) when compiling some projects on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Compile-time | Test Case: compile a crash | big web project Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by Ansible): * Attachment "epic.fail" added. scotty project 'epic' fails at the link step. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 22:07:29 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 22:07:29 -0000 Subject: [GHC] #10801: ghc returns ExitFailure (-4) when compiling some projects on ARM In-Reply-To: <046.137bdeead56cfd325f05891a55ecd378@haskell.org> References: <046.137bdeead56cfd325f05891a55ecd378@haskell.org> Message-ID: <061.d661c10ae5398d16e1362f45d3a37615@haskell.org> #10801: ghc returns ExitFailure (-4) when compiling some projects on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Compile-time | Test Case: compile a crash | big web project Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by Ansible): * Attachment "yesod-form.fail" added. yesod project - fail to install library yesod-form-1.4.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 27 23:57:30 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Aug 2015 23:57:30 -0000 Subject: [GHC] #10733: Improving the error message for type variable ambiguity In-Reply-To: <049.e68ae3d7f8aaef94b3cdeb692d3e5ac5@haskell.org> References: <049.e68ae3d7f8aaef94b3cdeb692d3e5ac5@haskell.org> Message-ID: <064.7690f4af1fd71c77d536c9ed1fe7faf7@haskell.org> #10733: Improving the error message for type variable ambiguity -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: kanetw Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1182 -------------------------------------+------------------------------------- Changes (by thomie): * differential: => Phab:D1182 * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 00:30:44 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 00:30:44 -0000 Subject: [GHC] #10733: Improving the error message for type variable ambiguity In-Reply-To: <049.e68ae3d7f8aaef94b3cdeb692d3e5ac5@haskell.org> References: <049.e68ae3d7f8aaef94b3cdeb692d3e5ac5@haskell.org> Message-ID: <064.8b7bae5ff0f7e25a1cbfad916046e8a9@haskell.org> #10733: Improving the error message for type variable ambiguity -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: kanetw Type: feature request | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1182 -------------------------------------+------------------------------------- Changes (by kanetw): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 01:04:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 01:04:01 -0000 Subject: [GHC] #10802: remote-debugger crashes with IntelliJ Haskell plugin in Mac OS X Message-ID: <044.1bc49ed60a1042e19b603eb4114b290b@haskell.org> #10802: remote-debugger crashes with IntelliJ Haskell plugin in Mac OS X -------------------------------------+------------------------------------- Reporter: smcho | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- With `cabal install remote-debugger` to use debugger in IntelliJ on Mac OS X, but I have "Debug execution error: Internel error occurred while executing debug process for ..." error when I tried to debug a program in IntelliJ. In command line, I got this error. {{{ ~> remote-debugger remote-debugger: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-apple-darwin): Main module not specified 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 Aug 28 01:05:22 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 01:05:22 -0000 Subject: [GHC] #10802: remote-debugger crashes with IntelliJ Haskell plugin in Mac OS X In-Reply-To: <044.1bc49ed60a1042e19b603eb4114b290b@haskell.org> References: <044.1bc49ed60a1042e19b603eb4114b290b@haskell.org> Message-ID: <059.4cc5a02adc5c3dd2bf5d13c595d741da@haskell.org> #10802: remote-debugger crashes with IntelliJ Haskell plugin in Mac OS X -------------------------------------+------------------------------------- Reporter: smcho | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by smcho: Old description: > With `cabal install remote-debugger` to use debugger in IntelliJ on Mac > OS X, but I have > > "Debug execution error: Internel error occurred while executing debug > process for ..." error when I tried to debug a program in IntelliJ. > > In command line, I got this error. > > {{{ > ~> remote-debugger > remote-debugger: panic! (the 'impossible' happened) > (GHC version 7.10.2 for x86_64-apple-darwin): > Main module not specified > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} New description: I used `cabal install remote-debugger` to use debugger in IntelliJ on Mac OS X. when I tried to debug a program in IntelliJ, I have "Debug execution error: Internel error occurred while executing debug process for ..." error In command line, I got this error with `remote-debugger`. {{{ ~> remote-debugger remote-debugger: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-apple-darwin): Main module not specified 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 Aug 28 03:45:10 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 03:45:10 -0000 Subject: [GHC] #10801: ghc returns ExitFailure (-4) when compiling some projects on ARM In-Reply-To: <046.137bdeead56cfd325f05891a55ecd378@haskell.org> References: <046.137bdeead56cfd325f05891a55ecd378@haskell.org> Message-ID: <061.10cc0134135f21ddd2da9ad5d76e995e@haskell.org> #10801: ghc returns ExitFailure (-4) when compiling some projects on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Compile-time | Test Case: compile a crash | big web project Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): 4 is `SIGILL` (illegal instruction) so this is probably the same issue as #10375 (running a TH splice) except with a 1000x more complicated reproducer :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 03:47:16 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 03:47:16 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.7c2946b1ee27697c28cfc257b820b277@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by rwbarton): Interesting that you see this behavior also from a compiled, non-threaded, statically linked (I assume) program. That should be much easier to debug. You are using the gold linker right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 03:52:58 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 03:52:58 -0000 Subject: [GHC] #10799: "I found a duplicate definition for symbol: __x86.get_pc_thunk.bx" in package network In-Reply-To: <047.a777ede82e63f4bc5c43944be8461ea4@haskell.org> References: <047.a777ede82e63f4bc5c43944be8461ea4@haskell.org> Message-ID: <062.5dd2e95ebf7b87fd4bf4c4136fde91c6@haskell.org> #10799: "I found a duplicate definition for symbol: __x86.get_pc_thunk.bx" in package network -------------------------------------+------------------------------------- Reporter: blueonyx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9657 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): A log file provided by the reporter on IRC showed Cabal building cbits with `ghc -fPIC`. I guess Cabal should really build cbits twice when it is building both a static and a dynamic library, ugh. It might also be worth implementing in the ghci linker whatever linker magic makes the system linker not complain about multiple copies of this symbol. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 06:53:12 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 06:53:12 -0000 Subject: [GHC] #10801: ghc returns ExitFailure (-4) when compiling some projects on ARM In-Reply-To: <046.137bdeead56cfd325f05891a55ecd378@haskell.org> References: <046.137bdeead56cfd325f05891a55ecd378@haskell.org> Message-ID: <061.cbed6986c0a31ee1027b5abb8a0c374d@haskell.org> #10801: ghc returns ExitFailure (-4) when compiling some projects on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Compile-time | Test Case: compile a crash | big web project Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Ansible): could be! the weird thing is I have 7.8.2 installed on another ARM computer and I've actually been able to build my project there. Maybe its a different 7.8.2. I'm afraid to touch anything on that one and cabal hasn't been updated in 150+ days. both are running arch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 07:05:47 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 07:05:47 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.6b65f3481b3d33c6a7e467ecb901e70d@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by Ansible): I did have the gold linker enabled when I did that test. since then I've gone back to arch and 7.8.2. ghc --info output is below (from debian jesse on raspberry pi 2): {{{ [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","/usr/bin/gcc") ,("C compiler flags"," -fno-stack-protector") ,("C compiler link flags"," -fuse-ld=gold -Wl,-z,noexecstack") ,("Haskell CPP command","/usr/bin/gcc") ,("Haskell CPP flags","-E -undef -traditional ") ,("ld command","/usr/bin/ld.gold") ,("ld flags"," -z noexecstack") ,("ld supports compact unwind","YES") ,("ld supports build-id","YES") ,("ld supports filelist","NO") ,("ld is GNU ld","YES") ,("ar command","/usr/bin/ar") ,("ar flags","q") ,("ar supports at file","YES") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("cross compiling","NO") ,("target os","OSLinux") ,("target arch","ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}") ,("target word size","4") ,("target has GNU nonexec stack","False") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("Unregisterised","NO") ,("LLVM llc command","/usr/bin/llc-3.5") ,("LLVM opt command","/usr/bin/opt-3.5") ,("Project version","7.10.2") ,("Project Git commit id","0da488c4438d88c9252e0b860426b8e74b5fc9e8") ,("Booter version","7.6.3") ,("Stage","2") ,("Build platform","arm-unknown-linux") ,("Host platform","arm-unknown-linux") ,("Target platform","arm-unknown-linux") ,("Have interpreter","YES") ,("Object splitting supported","NO") ,("Have native code generator","NO") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Support reexported-modules","YES") ,("Support thinning and renaming package flags","YES") ,("Uses package keys","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/usr/local/lib/ghc-7.10.2") ,("Global Package DB","/usr/local/lib/ghc-7.10.2/package.conf.d") ] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 07:07:15 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 07:07:15 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.5ec12f37a741e6f558e24e8bd7134b33@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by Ansible): although maybe gold would be a good thing to try on 7.8.2. hmm. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 07:18:21 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 07:18:21 -0000 Subject: [GHC] #9277: GHCi panic: Loading temp shared object failed: Symbol not found In-Reply-To: <045.813f344587210915a54c6a71c5a099a3@haskell.org> References: <045.813f344587210915a54c6a71c5a099a3@haskell.org> Message-ID: <060.407a1e5e0c3aa5db06458176b5803e9f@haskell.org> #9277: GHCi panic: Loading temp shared object failed: Symbol not found -------------------------------------+------------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: panic, | dynamic linking Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #8935, #9034, | Differential Revisions: #9074, #9278 | -------------------------------------+------------------------------------- Comment (by konn): I have a similar phenomenon with GHC 7.10.2 (installed with Haskell Platform) on OS X Yosemite 10.10.5. The same error also occurs when launching GHCi with `-package foo` where foo uses Obj-C code through FFI. Template Haskell uses GHCi internally, so this means that we can't use Template Haskell with Objective-C FFI. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 07:25:26 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 07:25:26 -0000 Subject: [GHC] #9766: Use TypeLits in the meta-data encoding of GHC.Generics In-Reply-To: <046.ac6e9deb0e3faceb7991565f7ad6b80b@haskell.org> References: <046.ac6e9deb0e3faceb7991565f7ad6b80b@haskell.org> Message-ID: <061.91d9fa46d54432bb31de426d5ab129f9@haskell.org> #9766: Use TypeLits in the meta-data encoding of GHC.Generics -------------------------------------+------------------------------------- Reporter: dreixel | Owner: kosmikus Type: task | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 9043 Related Tickets: #9043 | Differential Revisions: Phab:D493 -------------------------------------+------------------------------------- Changes (by simonpj): * owner: dreixel => kosmikus Comment: On the Phab ticket, Ben says > @dreixel, this looks like a nice use of promotion. Is there any chance you will be continuing this work? and Pedro replies > I'm afraid not, at least not in the foreseeable future. I'd love it if someone were to pick it up, though! I think that Andres has volunteered to pick up Generics related tickets, of which this is a prime example, so I'll change the owner to him. Andres, might you get to this? It's mostly done!! Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 07:37:30 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 07:37:30 -0000 Subject: [GHC] #10751: Implement Phase 1 of MonadFail Proposal (MFP) In-Reply-To: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> References: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> Message-ID: <057.09d2c95ded95b5170e477caf6cdbac04@haskell.org> #10751: Implement Phase 1 of MonadFail Proposal (MFP) -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: report- | impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > See also > > - > https://www.reddit.com/r/haskell/comments/3a1o06/monadfail_proposal_mfp/ > > TODO: At this point this ticket is mostly a reminder that stuff may need > to be done for GHC 7.12 New description: See also - https://www.reddit.com/r/haskell/comments/3a1o06/monadfail_proposal_mfp/ TODO: At this point this ticket is mostly a reminder that stuff may need to be done for GHC 7.12 David Luposchainsky [ https://mail.haskell.org/pipermail/ghc- devs/2015-August/009664.html says that he plans to work on it]. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 07:37:48 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 07:37:48 -0000 Subject: [GHC] #10751: Implement Phase 1 of MonadFail Proposal (MFP) In-Reply-To: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> References: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> Message-ID: <057.f281104f6f7f43a2a9be943ef682bc08@haskell.org> #10751: Implement Phase 1 of MonadFail Proposal (MFP) -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: report- | impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > See also > > - > https://www.reddit.com/r/haskell/comments/3a1o06/monadfail_proposal_mfp/ > > TODO: At this point this ticket is mostly a reminder that stuff may need > to be done for GHC 7.12 > > David Luposchainsky [ https://mail.haskell.org/pipermail/ghc- > devs/2015-August/009664.html says that he plans to work on it]. New description: See also - https://www.reddit.com/r/haskell/comments/3a1o06/monadfail_proposal_mfp/ TODO: At this point this ticket is mostly a reminder that stuff may need to be done for GHC 7.12 David Luposchainsky [https://mail.haskell.org/pipermail/ghc- devs/2015-August/009664.html says that he plans to work on it]. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 09:56:35 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 09:56:35 -0000 Subject: [GHC] #10801: ghc returns ExitFailure (-4) when compiling some projects on ARM In-Reply-To: <046.137bdeead56cfd325f05891a55ecd378@haskell.org> References: <046.137bdeead56cfd325f05891a55ecd378@haskell.org> Message-ID: <061.b1e357dc19e5cbdb916a681a604b848d@haskell.org> #10801: ghc returns ExitFailure (-4) when compiling some projects on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Compile-time | Test Case: compile a crash | big web project Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): For the record, GHC 7.8.2 is not the newest GHC release. GHC 7.10.2 has been released and we even have an [[https://www.haskell.org/ghc/download_ghc_7_10_2#linux_armv7 ARM bindist]]. GHC 7.8.2 was still a bit shaky on ARM (really, so is 7.10.2, unfortunately). To confirm, you are using `gold` to link your binaries, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 10:13:15 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 10:13:15 -0000 Subject: [GHC] #10802: remote-debugger crashes with IntelliJ Haskell plugin in Mac OS X In-Reply-To: <044.1bc49ed60a1042e19b603eb4114b290b@haskell.org> References: <044.1bc49ed60a1042e19b603eb4114b290b@haskell.org> Message-ID: <059.3bca253779a8e06b54d7455264beee7d@haskell.org> #10802: remote-debugger crashes with IntelliJ Haskell plugin in Mac OS X -------------------------------+------------------------------------------- Reporter: smcho | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: invalid | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+------------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => invalid * os: Unknown/Multiple => MacOS X * failure: None/Unknown => GHCi crash Comment: Does the GHCi debugger itself work? Despite the fact that the error asks that you report this as a GHC bug, I don't believe this is in fact a GHC bug. `remote-debugger` uses the GHC API, hence the error. In fact, there already appears to be a [https://github.com/octomarat/HaskellDebugger/issues/2 bug] filed against `remote-debugger` describing this exact issue. You may wish to bring this up there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 10:45:16 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 10:45:16 -0000 Subject: [GHC] #10803: New TypeSignatureSections extension Message-ID: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> #10803: New TypeSignatureSections extension -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- = Preliminary specification Have - `(::` ''type'' `)` be syntax sugar for - `(\x -> x ::` ''type'' `)` This new syntax extension is enabled via a new `TypeSignatureSections` language pragma, i.e. {{{#!hs {#- LANGUAGE TypeSignatureSections #-} }}} TODO: formalise this a bit more -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 10:45:25 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 10:45:25 -0000 Subject: [GHC] #10803: New TypeSignatureSections extension In-Reply-To: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> References: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> Message-ID: <057.396529c60df9ebe9592a954f00b38746@haskell.org> #10803: New TypeSignatureSections extension -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 10:53:34 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 10:53:34 -0000 Subject: [GHC] #10803: New TypeSignatureSections extension In-Reply-To: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> References: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> Message-ID: <057.b20a6d0886649e8cb9faab77faf5fd62@haskell.org> #10803: New TypeSignatureSections extension -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by spl): [http://augustss.blogspot.com/2014/04/a-small-haskell-extension.html Lennart Augustsson's proposal] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 10:54:41 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 10:54:41 -0000 Subject: [GHC] #10803: New TypeSignatureSections extension In-Reply-To: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> References: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> Message-ID: <057.8b8c3a57c2b28c54eaa493cdfdf5ea17@haskell.org> #10803: New TypeSignatureSections extension -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by spl): * cc: sean.leather@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 11:10:48 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 11:10:48 -0000 Subject: [GHC] #10803: New TypeSignatureSections extension In-Reply-To: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> References: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> Message-ID: <057.48906d18dfa06bdcf87c2a1ffe849f0d@haskell.org> #10803: New TypeSignatureSections extension -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hvr): The beginning of an implementation can be found in the [https://git.haskell.org/ghc.git/commitdiff/refs/heads/wip/T10803 wip/T10803] branch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 11:14:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 11:14:01 -0000 Subject: [GHC] #10804: Rules conditional on strictess properties Message-ID: <046.3487bb459d9772f684c8916eb3f609ee@haskell.org> #10804: Rules conditional on strictess properties -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Hi, This is taking note of a rough idea, i.e. something that I might want to investigate more deeply some day. The current libraries contain this code, which makes the compiler switch from `foldl` to `foldl'` for certain types where `min` is known to be strict in the first argument. {{{#!hs minimum :: (Ord a) => [a] -> a {-# INLINE [1] minimum #-} minimum [] = errorEmptyList "minimum" minimum xs = foldl1 min xs {-# RULES "minimumInt" minimum = (strictMinimum :: [Int] -> Int); "minimumInteger" minimum = (strictMinimum :: [Integer] -> Integer) #-} strictMinimum :: (Ord a) => [a] -> a strictMinimum [] = errorEmptyList "minimum" strictMinimum xs = foldl1' min xs }}} Is is a bit sad that this can only be done by listing explicit instances. What I would like to see is that it sufficies to write {{{#!hs minimum :: (Ord a) => [a] -> a {-# INLINE [1] minimum #-} minimum [] = errorEmptyList "minimum" minimum xs = foldl1 min xs }}} and then there are general rules taking care of choosing the right `foldl` variant: {{{#!hs {-# RULES "strict foldl" forall f. mumble_mumble f ==> foldl f = foldl' f "strict foldl1" forall f. mumble_mumble f ==> foldl1 f = foldl1' f #-} }}} The `mumble_mumble` would be some way of specifying the required strictness properties of `f`, which would be checked use the strictness analyzer. A simple `isStrict f` is probably not sufficient (The information that `f` is strict in the first argument also depends on how many arguments we pass to f, as `min ? ? ?`, but `?x. min ? x = ?`). Maybe `?x. min ? x = ?`, or some ASCIIfication of it, is indeed the proper sytanx.... This is related to #9137, which also wants conditional rewrite rules with certain compiler-checked aspectes of some of the matched variables. I think there is also a ticket (or at least an idea) about rewrite rules being conditional on some equation (e.g. (not very useful) `RULES forall f (*). (forall x y. x * y ? y * x) ==> foldl1 (*) (reverse xs) == foldl (*) xs`). I guess the rather vague #9601 covers that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 11:18:07 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 11:18:07 -0000 Subject: [GHC] #10803: New TypeSignatureSections extension In-Reply-To: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> References: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> Message-ID: <057.940e68b2670fbcf7a4d51a27316d2dd6@haskell.org> #10803: New TypeSignatureSections extension -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by hvr: Old description: > = Preliminary specification > > Have > > - `(::` ''type'' `)` > > be syntax sugar for > > - `(\x -> x ::` ''type'' `)` > > This new syntax extension is enabled via a new `TypeSignatureSections` > language pragma, i.e. > > {{{#!hs > {#- LANGUAGE TypeSignatureSections #-} > }}} > > TODO: formalise this a bit more New description: Originally [http://augustss.blogspot.co.at/2014/04/a-small-haskell- extension.html proposed by Lennart Augustsson] Incomplete work-in-progress can be found in [https://git.haskell.org/ghc.git/log/refs/heads/wip/T10803 wip/T10803] branch = Preliminary specification Have - `(::` ''type'' `)` be syntax sugar for - `(\x -> x ::` ''type'' `)` This new syntax extension is enabled via a new `TypeSignatureSections` language pragma, i.e. {{{#!hs {#- LANGUAGE TypeSignatureSections #-} }}} Typing judgement: {{{ _________________________ G ? (:: ty) :: ty -> ty }}} TODO: formalise this a bit more -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 11:20:04 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 11:20:04 -0000 Subject: [GHC] #10803: New TypeSignatureSections extension In-Reply-To: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> References: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> Message-ID: <057.af3f4a3b4ffd105d44e3dd26b19e0603@haskell.org> #10803: New TypeSignatureSections extension -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by hvr: Old description: > Originally [http://augustss.blogspot.co.at/2014/04/a-small-haskell- > extension.html proposed by Lennart Augustsson] > > Incomplete work-in-progress can be found in > [https://git.haskell.org/ghc.git/log/refs/heads/wip/T10803 wip/T10803] > branch > > = Preliminary specification > > Have > > - `(::` ''type'' `)` > > be syntax sugar for > > - `(\x -> x ::` ''type'' `)` > > This new syntax extension is enabled via a new `TypeSignatureSections` > language pragma, i.e. > > {{{#!hs > {#- LANGUAGE TypeSignatureSections #-} > }}} > > Typing judgement: > > {{{ > _________________________ > G ? (:: ty) :: ty -> ty > }}} > > TODO: formalise this a bit more New description: Originally [http://augustss.blogspot.co.at/2014/04/a-small-haskell- extension.html proposed by Lennart Augustsson] Incomplete work-in-progress can be found in [https://git.haskell.org/ghc.git/log/refs/heads/wip/T10803 wip/T10803] branch = Preliminary specification Have - `(::` ''type'' `)` be syntax sugar for - `(\x -> x ::` ''type'' `)` This new syntax extension is enabled via a new `TypeSignatureSections` language pragma, i.e. {{{#!hs {-# LANGUAGE TypeSignatureSections #-} }}} Typing judgement: {{{ _________________________ G ? (:: ty) :: ty -> ty }}} TODO: formalise this a bit more -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 12:41:26 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 12:41:26 -0000 Subject: [GHC] #10803: New TypeSignatureSections extension In-Reply-To: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> References: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> Message-ID: <057.a73abdc2b7d0d9caf84fcc1a8b4769e9@haskell.org> #10803: New TypeSignatureSections extension -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by hvr: Old description: > Originally [http://augustss.blogspot.co.at/2014/04/a-small-haskell- > extension.html proposed by Lennart Augustsson] > > Incomplete work-in-progress can be found in > [https://git.haskell.org/ghc.git/log/refs/heads/wip/T10803 wip/T10803] > branch > > = Preliminary specification > > Have > > - `(::` ''type'' `)` > > be syntax sugar for > > - `(\x -> x ::` ''type'' `)` > > This new syntax extension is enabled via a new `TypeSignatureSections` > language pragma, i.e. > > {{{#!hs > {-# LANGUAGE TypeSignatureSections #-} > }}} > > Typing judgement: > > {{{ > _________________________ > G ? (:: ty) :: ty -> ty > }}} > > TODO: formalise this a bit more New description: Originally [http://augustss.blogspot.co.at/2014/04/a-small-haskell- extension.html proposed by Lennart Augustsson] Incomplete work-in-progress can be found in [https://git.haskell.org/ghc.git/log/refs/heads/wip/T10803 wip/T10803] branch = Preliminary specification Have - `(::` ''type'' `)` be syntax sugar for - `(\x -> x ::` ''type'' `)` This new syntax extension is enabled via a new `SignatureSections` or maybe `TypeSignatureSections` language pragma, e.g. {{{#!hs {-# LANGUAGE TypeSignatureSections #-} }}} Typing judgement: {{{ _________________________ G ? (:: ty) :: ty -> ty }}} TODO: formalise this a bit more -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 14:49:28 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 14:49:28 -0000 Subject: [GHC] #9614: ghc --print-(gcc|ld)-linker-flags broken In-Reply-To: <047.8a05a0d53d11d93a9d7fdc38579c7742@haskell.org> References: <047.8a05a0d53d11d93a9d7fdc38579c7742@haskell.org> Message-ID: <062.434e83d521894bb18fd79d7f5a8449bb@haskell.org> #9614: ghc --print-(gcc|ld)-linker-flags broken -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 9421 Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 15:01:58 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 15:01:58 -0000 Subject: [GHC] #10801: ghc returns ExitFailure (-4) when compiling some projects on ARM In-Reply-To: <046.137bdeead56cfd325f05891a55ecd378@haskell.org> References: <046.137bdeead56cfd325f05891a55ecd378@haskell.org> Message-ID: <061.2d9e8ba02c3d1f7feee6374b87f01b60@haskell.org> #10801: ghc returns ExitFailure (-4) when compiling some projects on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Compile-time | Test Case: compile a crash | big web project Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Ansible): I'm glad to see an arm binary for 7.10.2, but it hasn't worked for me - it fails to compile 'hello world'. I didn't know gold was recommended for 7.8.2. I followed the procedure here for enabling it: https://wiki.archlinux.org/index.php/Gold_linker "ghc --info" still reports "("ld command","/usr/bin/ld")". I guess that's normal? Is there another way to enable gold? When I had debian jessie and 7.10.2, "ghc --info" reported gold as the 'ld command'. At any rate, this is what I get for ld --version. {{{ [bburdette at alarmpi epicmeatbars]$ ld --version GNU gold (GNU Binutils 2.25.1) 1.11 Copyright (C) 2014 Free Software Foundation, Inc. }}} Unfortunately this didn't allow the link to work in my 'epic' project, but maybe it would if I recompiled everything. I'll go ahead with that and see if it helps. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 15:38:57 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 15:38:57 -0000 Subject: [GHC] #10803: New TypeSignatureSections extension In-Reply-To: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> References: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> Message-ID: <057.7924b8d354d58b0c351d5c948eb57d5f@haskell.org> #10803: New TypeSignatureSections extension -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1185 -------------------------------------+------------------------------------- Changes (by hvr): * owner: => hvr * differential: => Phab:D1185 * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 15:39:08 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 15:39:08 -0000 Subject: [GHC] #10803: New TypeSignatureSections extension In-Reply-To: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> References: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> Message-ID: <057.3cf91377bc50097d34459900e2aebb94@haskell.org> #10803: New TypeSignatureSections extension -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature request | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1185 -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 16:28:57 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 16:28:57 -0000 Subject: [GHC] #10805: Could not deduce (a ~ b) implies (f a ~ f b), because a type function may not be injective Message-ID: <048.168c283eb65324145c2e904a0eeab833@haskell.org> #10805: Could not deduce (a ~ b) implies (f a ~ f b), because a type function may not be injective -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I don't know if the summary I provided is what's really going on here, but I'm a little baffled why this doesn't typecheck. I can't see what injectivity has to do with it, since we're not trying to deduce that the arguments are the same from the result of an application being the same; rather we're doing the opposite. I've encountered plenty of obvious arithmetic laws that I've needed to unsafeCoerceConstraint away with doing type level arithmetic, but this seems like it should be trivial regardless. {{{#!hs {-# LANGUAGE GADTs, ExplicitNamespaces, TypeOperators, DataKinds #-} {-# LANGUAGE ConstraintKinds, KindSignatures, PatternGuards #-} import Data.Type.Equality ((:~:)(..)) import GHC.TypeLits (Nat, type (<=), type (-), type (+), type (<=?)) data SNat :: Nat -> * where SSucc :: SNat a -> SNat (a + 1) SZero :: SNat 0 heqHet :: SNat a -> SNat b -> Maybe (a :~: b) heqHet SZero SZero = Just Refl heqHet (SSucc a) (SSucc b) | Just Refl <- heqHet a b = Just Refl heqHet _ _ = Nothing data Slice :: Nat -> Nat -> * where Slice :: ((start + 1) <= end, end <= numElements) => SNat numElements -> SNat start -> SNat end -> Slice numElements (end - start) heqHet' :: Slice a b -> Slice a b' -> Bool heqHet' (Slice _ start end) (Slice _ start' end') | Just _ <- heqHet start start' , Just _ <- heqHet end end' = True | otherwise = False }}} {{{#!hs Slice.hs:24:10: Could not deduce (((start + 1) <=? a) ~ ((start + 1) <=? a)) from the context (b ~ (end - start), (start + 1) <= end, end <= a) bound by a pattern with constructor Slice :: forall (numElements :: Nat) (start :: Nat) (end :: Nat). ((start + 1) <= end, end <= numElements) => SNat numElements -> SNat start -> SNat end -> Slice numElements (end - start), in an equation for ?heqHet'? at Slice.hs:24:10-26 or from (b' ~ (end1 - start1), (start1 + 1) <= end1, end1 <= a) bound by a pattern with constructor Slice :: forall (numElements :: Nat) (start :: Nat) (end :: Nat). ((start + 1) <= end, end <= numElements) => SNat numElements -> SNat start -> SNat end -> Slice numElements (end - start), in an equation for ?heqHet'? at Slice.hs:24:30-48 NB: ?GHC.TypeLits.<=?? is a type function, and may not be injective Relevant bindings include heqHet' :: Slice a b -> Slice a b' -> Bool (bound at Slice.hs:24:1) In the pattern: Slice _ start end In an equation for ?heqHet'?: heqHet' (Slice _ start end) (Slice _ start' end') | Just _ <- heqHet start start', Just _ <- heqHet end end' = True | otherwise = False Failed, modules loaded: none. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 16:33:23 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 16:33:23 -0000 Subject: [GHC] #10805: Could not deduce (a ~ b) implies (f a ~ f b), because a type function may not be injective In-Reply-To: <048.168c283eb65324145c2e904a0eeab833@haskell.org> References: <048.168c283eb65324145c2e904a0eeab833@haskell.org> Message-ID: <063.b9e43151475e66062f0fa80762855508@haskell.org> #10805: Could not deduce (a ~ b) implies (f a ~ f b), because a type function may not be injective -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by htebalaka): * status: new => closed * resolution: => fixed Comment: I found https://ghc.haskell.org/trac/ghc/ticket/10742, which appears to be the same thing and is fixed in HEAD, so I'm closing -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 16:35:22 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 16:35:22 -0000 Subject: [GHC] #10805: Could not deduce (a ~ b) implies (f a ~ f b), because a type function may not be injective In-Reply-To: <048.168c283eb65324145c2e904a0eeab833@haskell.org> References: <048.168c283eb65324145c2e904a0eeab833@haskell.org> Message-ID: <063.e55ca619a55019208f1f39f0e761c354@haskell.org> #10805: Could not deduce (a ~ b) implies (f a ~ f b), because a type function may not be injective -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Yes, it works fine in HEAD... I checked. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 16:51:40 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 16:51:40 -0000 Subject: [GHC] #10682: AArch64: dll-split: out of memory (requested 1099512676352 bytes) In-Reply-To: <044.b28ef9f55aa85f3be9d617cd7c0f70a5@haskell.org> References: <044.b28ef9f55aa85f3be9d617cd7c0f70a5@haskell.org> Message-ID: <059.89bc47b6ebc27cd67878babaae09ceaa@haskell.org> #10682: AArch64: dll-split: out of memory (requested 1099512676352 bytes) -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1171 -------------------------------------+------------------------------------- Comment (by Erik de Castro Lopo ): In [changeset:"38c98e4f61a48084995a5347d76ddd024ce1a09c/ghc" 38c98e4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="38c98e4f61a48084995a5347d76ddd024ce1a09c" RTS: Reduce MBLOCK_SPACE_SIZE on AArch64 Commit 0d1a8d09f4 added a two step allocator for 64 bit systems. This allocator mmaps a huge (1 TB) chunk of memory out of which it does smaller allocations. On AArch64/Arm64 linux, this mmap was failing due to the Arm64 Linux kernel parameter CONFIG_ARM64_VA_BITS defaulting to 39 bits. Therefore reducing the AArch64 value for MBLOCK_SPACE_SIZE to make this allocation 1/4 TB while remaining 1 TB for other archs. Reviewers: ezyang, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1171 GHC Trac Issues: #10682 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 17:52:45 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 17:52:45 -0000 Subject: [GHC] #10801: ghc returns ExitFailure (-4) when compiling some projects on ARM In-Reply-To: <046.137bdeead56cfd325f05891a55ecd378@haskell.org> References: <046.137bdeead56cfd325f05891a55ecd378@haskell.org> Message-ID: <061.2cc3f1c458f87b0ee1a6daf4a5092210@haskell.org> #10801: ghc returns ExitFailure (-4) when compiling some projects on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Compile-time | Test Case: compile a crash | big web project Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Ansible): The build with gold was going ok but it got stuck on this: {{{ [bburdette at alarmpi epicmeatbars]$ cabal -j1 install stm-chans-3.0.0.4 Resolving dependencies... [1 of 1] Compiling Main ( /home/bburdette/code/stm- chans-3.0.0.4/dist/dist-sandbox-491b648e/setup/setup.hs, /home/bburdette/code/stm-chans-3.0.0.4/dist/dist-sandbox- 491b648e/setup/Main.o ) Linking /home/bburdette/code/stm-chans-3.0.0.4/dist/dist-sandbox- 491b648e/setup/setup ... /usr/local/bin/ld: error: /usr/lib/ghc-7.8.2/process-1.2.0.0/libHSprocess-1.2.0.0.a(runProcess.o): requires unsupported dynamic reloc R_ARM_MOVW_ABS_NC; recompile with -fPIC /usr/local/bin/ld: error: /usr/lib/ghc-7.8.2/rts-1.0/libHSrts_thr.a(GetTime.thr_o): requires unsupported dynamic reloc R_ARM_MOVW_ABS_NC; recompile with -fPIC collect2: error: ld returned 1 exit status Failed to install stm-chans-3.0.0.4 }}} I tried adding -fPIC to the stm-chan cabal, but I think it wants me to do that with process and rts. I found process-1.2.0 so I can add-source that to my sandbox with -fPIC enabled, but I don't know where rts is. I didn't see it on hackage. Maybe its part of ghc? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 18:36:50 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 18:36:50 -0000 Subject: [GHC] #10751: Implement Phase 1 of MonadFail Proposal (MFP) In-Reply-To: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> References: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> Message-ID: <057.59d42cd7053e45a4ba5c6ca5825056a1@haskell.org> #10751: Implement Phase 1 of MonadFail Proposal (MFP) -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: report- | impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by quchen): Current status: - Warnings are issued for missing MonadFail instances. These warnings are on by default and can be toggled with a flag. - The (->)r Monad doesn't yield the correct error message yet: it displays as "m r" in the "missing MonadFail" message. - There is a flag to turn on the actual desugaring. It's turned off by default, but can be used to get a hard error if something's been forgotten. - The testsuite has been mostly fixed (not sure whether the failing tests are our fault, didn't check it yet) - We have lots of WIP commits that aren't very good versioning practice, so the actual patch will need to be squashed down to a handful of useful ones. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 18:48:10 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 18:48:10 -0000 Subject: [GHC] #10801: ghc returns ExitFailure (-4) when compiling some projects on ARM In-Reply-To: <046.137bdeead56cfd325f05891a55ecd378@haskell.org> References: <046.137bdeead56cfd325f05891a55ecd378@haskell.org> Message-ID: <061.40f07c99568fdf58f096f77d8abd8c42@haskell.org> #10801: ghc returns ExitFailure (-4) when compiling some projects on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Compile-time | Test Case: compile a crash | big web project Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Ansible): ok fwiw I tried a "cabal -j1 install yesod-form-1.4.4.1" on the other project. That ended in a ExitFailure(-11) instead of -4. I didn't try to recompile everything for that though, just ran it as-is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 18:52:06 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 18:52:06 -0000 Subject: [GHC] #10801: ghc returns ExitFailure (-4) when compiling some projects on ARM In-Reply-To: <046.137bdeead56cfd325f05891a55ecd378@haskell.org> References: <046.137bdeead56cfd325f05891a55ecd378@haskell.org> Message-ID: <061.e23b7c90cb8b2eee539e29eef5f25145@haskell.org> #10801: ghc returns ExitFailure (-4) when compiling some projects on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Compile-time | Test Case: compile a crash | big web project Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => wontfix Comment: Oh I didn't notice earlier that this was 7.8.2. I recommend not going down this particular rabbit hole with 7.8.2 since there will not be a new release in the 7.8 line anyways (not to mention that 7.8.2 is not even the latest 7.8 release). You should try to get 7.10 working instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 19:02:19 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 19:02:19 -0000 Subject: [GHC] #10801: ghc returns ExitFailure (-4) when compiling some projects on ARM In-Reply-To: <046.137bdeead56cfd325f05891a55ecd378@haskell.org> References: <046.137bdeead56cfd325f05891a55ecd378@haskell.org> Message-ID: <061.223df80d1454529b0ba15843722fa9d0@haskell.org> #10801: ghc returns ExitFailure (-4) when compiling some projects on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Compile-time | Test Case: compile a crash | big web project Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Ansible): ah. unfortunately 7.10.2 can't even compile 'hello world', much less cabal. Well it can compile 'hello world' but the resulting executable crashes. According to comments here: [https://ghc.haskell.org/trac/ghc/ticket/10375], the illegal instruction error that is currently crippling 7.10.2 has been around since at least 7.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 19:39:21 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 19:39:21 -0000 Subject: [GHC] #10806: Type error and type level (<=) together cause GHC to hang Message-ID: <048.9b3d349db1bfdcff1a2e281d43595c9a@haskell.org> #10806: Type error and type level (<=) together cause GHC to hang -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: | Operating System: MacOS X Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The following incorrect type in the function wrongArity triggers an infinite loop in GHC, though only in the presence of triggersLoop. The issue is somehow related to the use of (<=) in constraints of the Q data constructor; if I remove either of the constraints or add an (a <= c) constraint it works as you would expect. {{{#!hs {-# LANGUAGE GADTs, ExplicitNamespaces, TypeOperators, DataKinds #-} import GHC.TypeLits (Nat, type (<=)) data Q a where Q :: (a <= b, b <= c) => proxy a -> proxy b -> Q c wrongArity :: a -> a wrongArity _ a = a triggersLoop :: Q b -> Q b -> Bool triggersLoop (Q _ _) (Q _ _) = undefined }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 20:21:03 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 20:21:03 -0000 Subject: [GHC] #10806: Type error and type level (<=) together cause GHC to hang In-Reply-To: <048.9b3d349db1bfdcff1a2e281d43595c9a@haskell.org> References: <048.9b3d349db1bfdcff1a2e281d43595c9a@haskell.org> Message-ID: <063.30994f717e9ab6826840faba4f7ef969@haskell.org> #10806: Type error and type level (<=) together cause GHC to hang -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by htebalaka: Old description: > The following incorrect type in the function wrongArity triggers an > infinite loop in GHC, though only in the presence of triggersLoop. The > issue is somehow related to the use of (<=) in constraints of the Q data > constructor; if I remove either of the constraints or add an (a <= c) > constraint it works as you would expect. > {{{#!hs > > {-# LANGUAGE GADTs, ExplicitNamespaces, TypeOperators, DataKinds #-} > > import GHC.TypeLits (Nat, type (<=)) > > data Q a where > Q :: (a <= b, b <= c) => proxy a -> proxy b -> Q c > > wrongArity :: a -> a > wrongArity _ a = a > > triggersLoop :: Q b -> Q b -> Bool > triggersLoop (Q _ _) (Q _ _) = undefined > }}} New description: The following incorrect type in the function wrongArity triggers an infinite loop at compile time, though only in the presence of triggersLoop. The issue is somehow related to the use of (<=) in constraints of the Q data constructor; if I remove either of the constraints or add an (a <= c) constraint it works as you would expect. {{{#!hs {-# LANGUAGE GADTs, ExplicitNamespaces, TypeOperators, DataKinds #-} import GHC.TypeLits (Nat, type (<=)) data Q a where Q :: (a <= b, b <= c) => proxy a -> proxy b -> Q c wrongArity :: a -> a wrongArity _ a = a triggersLoop :: Q b -> Q b -> Bool triggersLoop (Q _ _) (Q _ _) = undefined }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 20:47:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 20:47:01 -0000 Subject: [GHC] #10807: PatternGuards and MultiWayIf layout rules Message-ID: <048.5f26fa8ef546300efdabaf52e9225195@haskell.org> #10807: PatternGuards and MultiWayIf layout rules -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The layout rules for MultiWayIf currently require any lines starting with a comma to be further indented than the lines starting with a pipe when used in conjunction with PatternGuards. This is inconsistent with the examples given in [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/syntax- extns.html#pattern-guards]. For instance, we can't use the same indentation in the second example as in the first without triggering a parser error. {{{#!hs {-# LANGUAGE PatternGuards, MultiWayIf fine a pred | Just x <- a , pred x = True | otherwise = False notFine a pred = if | Just x <- a , pred x -> True | otherwise -> False }}} Though the documentation isn't ''incorrect'', if this intentional it could be pointed out, since it's counterintuitive. Otherwise, if there's no reason for MulitWayIf to require further indentation that should be fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 21:36:10 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 21:36:10 -0000 Subject: [GHC] #10806: Type error and type level (<=) together cause GHC to hang In-Reply-To: <048.9b3d349db1bfdcff1a2e281d43595c9a@haskell.org> References: <048.9b3d349db1bfdcff1a2e281d43595c9a@haskell.org> Message-ID: <063.6c56e3bad5285774ef7cee376cb7c4fb@haskell.org> #10806: Type error and type level (<=) together cause GHC to hang -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by htebalaka: Old description: > The following incorrect type in the function wrongArity triggers an > infinite loop at compile time, though only in the presence of > triggersLoop. The issue is somehow related to the use of (<=) in > constraints of the Q data constructor; if I remove either of the > constraints or add an (a <= c) constraint it works as you would expect. > {{{#!hs > > {-# LANGUAGE GADTs, ExplicitNamespaces, TypeOperators, DataKinds #-} > > import GHC.TypeLits (Nat, type (<=)) > > data Q a where > Q :: (a <= b, b <= c) => proxy a -> proxy b -> Q c > > wrongArity :: a -> a > wrongArity _ a = a > > triggersLoop :: Q b -> Q b -> Bool > triggersLoop (Q _ _) (Q _ _) = undefined > }}} New description: The following incorrect arity triggers an infinite loop at compile time. The issue is somehow related to the use of (<=) in constraints of the Q data constructor; if I remove either of the constraints or add an (a <= c) constraint it works as you would expect. {{{#!hs {-# LANGUAGE GADTs, ExplicitNamespaces, TypeOperators, DataKinds #-} import GHC.TypeLits (Nat, type (<=)) data Q a where Q :: (a <= b, b <= c) => proxy a -> proxy b -> Q c triggersLoop :: Q b -> Q b -> Bool triggersLoop (Q _ _) (Q _ _) = print 'x' 'y' }}} Incorrect function definitions, like {{{foo :: a -> a ; foo _ x = x}}} also result in an infinite loop. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 22:08:35 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 22:08:35 -0000 Subject: [GHC] #4505: Segmentation fault on long input (list of pairs) In-Reply-To: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> References: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> Message-ID: <061.1d3b2769bb57dae1aa410969da6e97fd@haskell.org> #4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: | Segmentation fault, segfault, long | input Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: 4258 | Blocking: Related Tickets: | Differential Revisions: Phab:D1180 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * differential: D1180 => Phab:D1180 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 22:24:45 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 22:24:45 -0000 Subject: [GHC] #10807: PatternGuards and MultiWayIf layout rules In-Reply-To: <048.5f26fa8ef546300efdabaf52e9225195@haskell.org> References: <048.5f26fa8ef546300efdabaf52e9225195@haskell.org> Message-ID: <063.69c5c52a0a905d80831a4df3bff7178a@haskell.org> #10807: PatternGuards and MultiWayIf layout rules -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #7783 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * type: task => bug * related: => #7783 Old description: > The layout rules for MultiWayIf currently require any lines starting with > a comma to be further indented than the lines starting with a pipe when > used in conjunction with PatternGuards. This is inconsistent with the > examples given in > [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/syntax- > extns.html#pattern-guards]. For instance, we can't use the same > indentation in the second example as in the first without triggering a > parser error. > > {{{#!hs > {-# LANGUAGE PatternGuards, MultiWayIf > > fine a pred > | Just x <- a > , pred x = True > | otherwise = False > > notFine a pred = > if | Just x <- a > , pred x -> True > | otherwise -> False > }}} > > Though the documentation isn't ''incorrect'', if this intentional it > could be pointed out, since it's counterintuitive. Otherwise, if there's > no reason for MulitWayIf to require further indentation that should be > fixed. New description: The layout rules for MultiWayIf currently require any lines starting with a comma to be further indented than the lines starting with a pipe when used in conjunction with PatternGuards. This is inconsistent with the examples given in [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/syntax- extns.html#pattern-guards]. For instance, we can't use the same indentation in the second example as in the first without triggering a parser error. {{{#!haskell {-# LANGUAGE PatternGuards, MultiWayIf #} fine a pred | Just x <- a , pred x = True | otherwise = False notFine a pred = if | Just x <- a , pred x -> True | otherwise -> False }}} Though the documentation isn't ''incorrect'', if this intentional it could be pointed out, since it's counterintuitive. Otherwise, if there's no reason for MulitWayIf to require further indentation that should be fixed. -- Comment: Looks like a parser bug to me. The following comment in `Parser.y` (introduced in #7783) seems to hint at the problem: {{{ -- layout for MultiWayIf doesn't begin with an open brace, because it's hard to -- generate the open brace in addition to the vertical bar in the lexer, and -- we don't need it. }}} With braces the example compiles fine: {{{#!haskell fineAgain a pred = if { | Just x <- a , pred x -> True | otherwise -> False } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 28 22:25:41 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Aug 2015 22:25:41 -0000 Subject: [GHC] #10807: PatternGuards and MultiWayIf layout rules In-Reply-To: <048.5f26fa8ef546300efdabaf52e9225195@haskell.org> References: <048.5f26fa8ef546300efdabaf52e9225195@haskell.org> Message-ID: <063.ed924767c9e3f0b9a747d9811e33cc92@haskell.org> #10807: PatternGuards and MultiWayIf layout rules -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #7783 | Differential Revisions: -------------------------------------+------------------------------------- Description changed by thomie: Old description: > The layout rules for MultiWayIf currently require any lines starting with > a comma to be further indented than the lines starting with a pipe when > used in conjunction with PatternGuards. This is inconsistent with the > examples given in > [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/syntax- > extns.html#pattern-guards]. For instance, we can't use the same > indentation in the second example as in the first without triggering a > parser error. > > {{{#!haskell > {-# LANGUAGE PatternGuards, MultiWayIf #} > > fine a pred > | Just x <- a > , pred x = True > | otherwise = False > > notFine a pred = > if | Just x <- a > , pred x -> True > | otherwise -> False > }}} > > Though the documentation isn't ''incorrect'', if this intentional it > could be pointed out, since it's counterintuitive. Otherwise, if there's > no reason for MulitWayIf to require further indentation that should be > fixed. New description: The layout rules for MultiWayIf currently require any lines starting with a comma to be further indented than the lines starting with a pipe when used in conjunction with PatternGuards. This is inconsistent with the examples given in [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/syntax- extns.html#pattern-guards]. For instance, we can't use the same indentation in the second example as in the first without triggering a parser error. {{{#!haskell {-# LANGUAGE PatternGuards, MultiWayIf #-} fine a pred | Just x <- a , pred x = True | otherwise = False notFine a pred = if | Just x <- a , pred x -> True | otherwise -> False }}} Though the documentation isn't ''incorrect'', if this intentional it could be pointed out, since it's counterintuitive. Otherwise, if there's no reason for MulitWayIf to require further indentation that should be fixed. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 29 02:52:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Aug 2015 02:52:36 -0000 Subject: [GHC] #10413: Incorrect offsets for array size indexing In-Reply-To: <048.fb282c815f959019fb8541a09f28e9ea@haskell.org> References: <048.fb282c815f959019fb8541a09f28e9ea@haskell.org> Message-ID: <063.aa0693890dc9a61bd8b8826b8d8d9ac9@haskell.org> #10413: Incorrect offsets for array size indexing -------------------------------------+------------------------------------- Reporter: fryguybob | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * cc: ekmett (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 29 03:17:35 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Aug 2015 03:17:35 -0000 Subject: [GHC] #10808: Odd interaction between record update and type families Message-ID: <047.471f8f83366e55a5ccef63da38ac6240@haskell.org> #10808: Odd interaction between record update and type families -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Consider the following example {{{#!hs {-# LANGUAGE TypeFamilies #-} type family F a type family G a data T1 type instance F T1 = Char type instance G T1 = Int data T2 type instance F T2 = Bool type instance G T2 = Int data R a = R { x :: F a, y :: G a } r1 :: R T1 r1 = R { x = 'a', y = 2 } r2 :: R T2 r2 = r1 { x = True } -- error: Cannot match T1 with T2 r3 :: R T2 r3 = r1 { x = True, y = y r1 } -- OK }}} The error for `r2` is odd because types `R T1` and `R T2` differ only in the type of `x`, so if we start with a value of type `R T1`, and update the field where the types differ, we should end up with a valid value of type `R T2`. The fact that `r2` is OK is demonstrated by `r3` where we update the other field with its own value, and now the type checker is happy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 29 03:22:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Aug 2015 03:22:41 -0000 Subject: [GHC] #10809: Add prefetch{Small}{Mutable}Array[0..3]# Message-ID: <045.362862b9c795f03f22e13a10bddfcc8c@haskell.org> #10809: Add prefetch{Small}{Mutable}Array[0..3]# -------------------------------------+------------------------------------- Reporter: ekmett | Owner: simonmar Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 7.10.2 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- We now have a number of prefetch operations: {{{ prefetchAddr0# prefetchMutableByteArray0# prefetchAddr1# prefetchMutableByteArray1# prefetchAddr2# prefetchMutableByteArray2# prefetchAddr3# prefetchMutableByteArray3# prefetchByteArray0# prefetchValue0# prefetchByteArray1# prefetchValue1# prefetchByteArray2# prefetchValue2# prefetchByteArray3# prefetchValue3# }}} but we are missing variants for fetching slots of a `{Small}{Mutable}Array#`. This differs from fetching the item pointed to by the entry at that address, so `prefetchValueX` does us no good there. Basically this just needs to compute the offset of the appropriate slot and prefetch the memory for that portion of the array as an address like we do indexing into a byte array. I have some code that could benefit a fair bit from being able to prefetch a binary search on array elements this way, when storing those elements either in a traditional sorted order or Eytzinger layout. I've verified this experimentally by unsafeCoercing existing bytearray primitives to make them work on other array types. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 29 03:23:12 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Aug 2015 03:23:12 -0000 Subject: [GHC] #10809: Add prefetch{Small}{Mutable}Array[0..3]# In-Reply-To: <045.362862b9c795f03f22e13a10bddfcc8c@haskell.org> References: <045.362862b9c795f03f22e13a10bddfcc8c@haskell.org> Message-ID: <060.00e27bda90e2f06b277c9dd612d1e3d0@haskell.org> #10809: Add prefetch{Small}{Mutable}Array[0..3]# -------------------------------------+------------------------------------- Reporter: ekmett | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * cc: carter (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 29 04:05:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Aug 2015 04:05:36 -0000 Subject: [GHC] #10810: Data constructor operators mis-printed in Template Haskell Message-ID: <047.9a0eacfe35e8d9bc3ca01ce57985f5f2@haskell.org> #10810: Data constructor operators mis-printed in Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Template | Version: 7.10.2 Haskell | Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices -dsuppress-uniques #-} module Bug where $([d| data Foo = (:!) |]) }}} I get {{{ Bug.hs:6:3-24: Splicing declarations [d| data Foo = :! |] ======> data Foo = :! }}} There are missing parentheses in that output. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 29 04:12:48 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Aug 2015 04:12:48 -0000 Subject: [GHC] #10811: Template Haskell does associated types poorly (printing & quoting) Message-ID: <047.eefd4e69268b49667f9aa1e189a8806f@haskell.org> #10811: Template Haskell does associated types poorly (printing & quoting) -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Template | Version: 7.10.2 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE TemplateHaskell, TypeFamilies #-} {-# OPTIONS_GHC -ddump-splices -dsuppress-uniques #-} module Bug where $([d| class C a where type F a type F a = a |]) }}} I get {{{ [d| class C a where type family F a F a = a |] ======> Bug.hs:6:7: Warning: Cannot desugar this Template Haskell declaration: class C a where type family F a F a = a }}} There are two problems here: 1. This really should work. 2. The pretty-printer here omits the `type` on the default definition for `F`. (The word `family` is optional there, but isn't actually wrong.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 29 07:06:15 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Aug 2015 07:06:15 -0000 Subject: [GHC] #10808: Odd interaction between record update and type families In-Reply-To: <047.471f8f83366e55a5ccef63da38ac6240@haskell.org> References: <047.471f8f83366e55a5ccef63da38ac6240@haskell.org> Message-ID: <062.175f7098135e5e3249656e44f96389a2@haskell.org> #10808: Odd interaction between record update and type families -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by glguy): * cc: glguy (added) * failure: None/Unknown => GHC rejects valid program -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 29 08:39:46 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Aug 2015 08:39:46 -0000 Subject: [GHC] #10806: Type error and type level (<=) together cause GHC to hang In-Reply-To: <048.9b3d349db1bfdcff1a2e281d43595c9a@haskell.org> References: <048.9b3d349db1bfdcff1a2e281d43595c9a@haskell.org> Message-ID: <063.c9edec985c313e773083565479855476@haskell.org> #10806: Type error and type level (<=) together cause GHC to hang -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 7.12.1 Comment: Oh dear. This should certainly be addressed for 7.12 if possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 29 11:25:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Aug 2015 11:25:32 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.3b2ab4611dc5c70ba3dadcfb46692b24@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, | deepseq, evaluate, exceptions Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #5129 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"15cb83d4e98c2c356bf0e3eb0df6d322755337bd/ghc" 15cb83d4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="15cb83d4e98c2c356bf0e3eb0df6d322755337bd" Add testcase for #7411 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 29 11:25:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Aug 2015 11:25:32 -0000 Subject: [GHC] #10775: Enable PolyKinds in GHC.Generics In-Reply-To: <050.1fb49e8a4f9e9ff5b73b6dbae85f944e@haskell.org> References: <050.1fb49e8a4f9e9ff5b73b6dbae85f944e@haskell.org> Message-ID: <065.5b990ac6937ab382e4ed19b9da184e70@haskell.org> #10775: Enable PolyKinds in GHC.Generics -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: | RyanGlScott Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1166 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"a6826c5d18675a783acce39352eea283e462bf8b/ghc" a6826c5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a6826c5d18675a783acce39352eea283e462bf8b" Make Generic (Proxy t) instance poly-kinded (fixes #10775) This amounts to enabling PolyKinds in GHC.Generics. However, explicit kind signatures must be applied to the datatypes and typeclasses in GHC.Generics to ensure that the Core which TcGenGenerics generates is properly kinded. Several of the typeclasses in GHC.Generics could be poly-kinded, but this differential does not attempt to address this, since D493 already addresses this. Test Plan: ./validate Reviewers: hvr, austin, dreixel, bgamari Reviewed By: austin, dreixel, bgamari Subscribers: goldfire, thomie Differential Revision: https://phabricator.haskell.org/D1166 GHC Trac Issues: #10775 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 29 11:25:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Aug 2015 11:25:32 -0000 Subject: [GHC] #10762: On Windows, out-of-codepage characters can cause GHC build to fail In-Reply-To: <047.594293f39928454a6845b64e2efaf718@haskell.org> References: <047.594293f39928454a6845b64e2efaf718@haskell.org> Message-ID: <062.cd1277799f1aba58d0eeff58c22a8151@haskell.org> #10762: On Windows, out-of-codepage characters can cause GHC build to fail ---------------------------------+----------------------------------------- Reporter: snoyberg | Owner: snoyberg Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6037 | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by Ben Gamari ): In [changeset:"1b56c40578374a15b4a2593895710c68b0e2a717/ghc" 1b56c405/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1b56c40578374a15b4a2593895710c68b0e2a717" Respect GHC_CHARENC environment variable #10762 Only supports UTF-8 as a value right now. I expect some discussion to go on around the naming of this variable and whether it's valid to backport it to GHC 7.10 (which would be my preference). The motivation here is that, when capturing the output of GHC to a file, we often want to ensure that the output is UTF-8, regardless of the actual character encoding of the terminal/console. On the other hand, we don't want to necessary change the terminal/console encoding. The reason being: * On Windows, this requires a global-esque change to the console codepage, which adversely affects other processes in the same console * On all OSes, this can break features like smart quote auto-detection. Test Plan: Set LANG to C, GHC_CHARENC to UTF-8, and compile a Haskell source file with a non-ASCII warning produced. The output who include the UTF-8 sequence instead of replacing it with ?. Reviewers: austin, rwbarton, bgamari Reviewed By: bgamari Subscribers: hsyl20, thomie Differential Revision: https://phabricator.haskell.org/D1167 GHC Trac Issues: #10762 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 29 11:25:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Aug 2015 11:25:32 -0000 Subject: [GHC] #10661: Regression: hp2ps reports `integer unexpected` on new style package keys In-Reply-To: <045.9c4a37e2fa0ae7c34e598ac5ff3e0cab@haskell.org> References: <045.9c4a37e2fa0ae7c34e598ac5ff3e0cab@haskell.org> Message-ID: <060.f1e1ba8133da4e5b4573119da346fadb@haskell.org> #10661: Regression: hp2ps reports `integer unexpected` on new style package keys -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.12.1 Component: Profiling | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | concurrent/prog002/concprog002 Blocked By: | Blocking: Related Tickets: #10550 | Differential Revisions: Phab:D1175 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0c823af84d80ac103528e54eda8e1c6bdf2bea69/ghc" 0c823af8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0c823af84d80ac103528e54eda8e1c6bdf2bea69" Fix identifier parsing in hp2ps Now identifiers can start with a package key, which is a hash, so they may also start with a digit. Identifiers always appear at the beginning of a line, and numbers never appear here, soit's safe to allow identifiers to start with a digit. Test Plan: `concprog002` passes under `threaded2_hT` way Reviewers: austin, bgamari, thomie Reviewed By: austin, bgamari, thomie Differential Revision: https://phabricator.haskell.org/D1175 GHC Trac Issues: #10661 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 29 11:25:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Aug 2015 11:25:32 -0000 Subject: [GHC] #4505: Segmentation fault on long input (list of pairs) In-Reply-To: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> References: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> Message-ID: <061.3550aaadd55b68a5a89bc84eba505130@haskell.org> #4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: | Segmentation fault, segfault, long | input Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: 4258 | Blocking: Related Tickets: | Differential Revisions: Phab:D1180 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c1d7b4b43bbc4c7a590a8b942adc09e654d0659d/ghc" c1d7b4b4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c1d7b4b43bbc4c7a590a8b942adc09e654d0659d" StgCmmHeap: Re-add check for large static allocations This should at least help alleviate the annoyance of #4505. This reintroduces a compile-time check originally added in a278f3f02d09bc32b0a75d4a04d710090cde250f but dropped with the new code generator. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 29 11:40:56 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Aug 2015 11:40:56 -0000 Subject: [GHC] #10661: Regression: hp2ps reports `integer unexpected` on new style package keys In-Reply-To: <045.9c4a37e2fa0ae7c34e598ac5ff3e0cab@haskell.org> References: <045.9c4a37e2fa0ae7c34e598ac5ff3e0cab@haskell.org> Message-ID: <060.bee6b23d064e74525e29cdbd86be8a9a@haskell.org> #10661: Regression: hp2ps reports `integer unexpected` on new style package keys -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.12.1 Component: Profiling | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | concurrent/prog002/concprog002 Blocked By: | Blocking: Related Tickets: #10550 | Differential Revisions: Phab:D1175 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 29 11:42:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Aug 2015 11:42:32 -0000 Subject: [GHC] #10775: Enable PolyKinds in GHC.Generics In-Reply-To: <050.1fb49e8a4f9e9ff5b73b6dbae85f944e@haskell.org> References: <050.1fb49e8a4f9e9ff5b73b6dbae85f944e@haskell.org> Message-ID: <065.11bdba22e7721158c082707687b73c21@haskell.org> #10775: Enable PolyKinds in GHC.Generics -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: | RyanGlScott Type: feature request | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1166 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 29 11:44:17 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Aug 2015 11:44:17 -0000 Subject: [GHC] #4505: Segmentation fault on long input (list of pairs) In-Reply-To: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> References: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> Message-ID: <061.53c0186edc27bb58bf8e22d8279e822e@haskell.org> #4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: | Segmentation fault, segfault, long | input Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: 4258 | Blocking: Related Tickets: | Differential Revisions: Phab:D1180 -------------------------------------+------------------------------------- Comment (by bgamari): Re-added the compile-time check but it would be nice to resolve the underlying RTS issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 29 14:28:50 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Aug 2015 14:28:50 -0000 Subject: [GHC] #10806: Type error and type level (<=) together cause GHC to hang In-Reply-To: <048.9b3d349db1bfdcff1a2e281d43595c9a@haskell.org> References: <048.9b3d349db1bfdcff1a2e281d43595c9a@haskell.org> Message-ID: <063.f3c6cfd63daf42064882c3c4ebaa8c5a@haskell.org> #10806: Type error and type level (<=) together cause GHC to hang -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by htebalaka): Just to be clear, function definitions with the wrong arity still needed {{{triggersLoop (Q _ _) (Q _ _) = undefined}}} to trigger the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 29 15:22:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Aug 2015 15:22:22 -0000 Subject: [GHC] #10812: High memory usage Message-ID: <046.80aa46a375cd3a278869ea812244030d@haskell.org> #10812: High memory usage -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Hello, lets consider following program: {{{ {-# LANGUAGE NoMonomorphismRestriction #-} import System.Mem.Weak import Control.Concurrent import System.Mem data Tst a = Tst a deriving (Show, Eq) tst a = do let arr = [0 .. a*a*a] v = Tst (seq arr arr) ptr <- mkWeakPtr v Nothing return ptr main = do ptrs <- mapM tst [1..100000000] --performGC --performMajorGC --performMinorGC threadDelay 1000000 xr <- mapM deRefWeak ptrs print $ length $ filter (/= Nothing) xr threadDelay 5000000 return () }}} It simply creates 10 million of weak references to values of {{{Tst}}}. These weak pointers are returned in the main function. After that we sleep a second and ask how meany references are alive. I get the {{{0}}} as a result here - so everything seems ok - garbage collection worked. There is a problem though - somehow the memory was not released, because on the second 5-second sleep the program uses over 14 Gb of RAM on my computer. I'm compiling it simply with {{{ghc -O2 Main.hs}}}. I'm pretty sure this is a bug, because such behaviour is not expected I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 29 15:28:55 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Aug 2015 15:28:55 -0000 Subject: [GHC] #10812: High memory usage In-Reply-To: <046.80aa46a375cd3a278869ea812244030d@haskell.org> References: <046.80aa46a375cd3a278869ea812244030d@haskell.org> Message-ID: <061.29414217fd0388759031856bdbe21ecf@haskell.org> #10812: High memory usage ---------------------------------+----------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Changes (by danilo2): * os: Unknown/Multiple => MacOS X * architecture: Unknown/Multiple => x86_64 (amd64) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 29 16:17:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Aug 2015 16:17:10 -0000 Subject: [GHC] #10812: High memory usage In-Reply-To: <046.80aa46a375cd3a278869ea812244030d@haskell.org> References: <046.80aa46a375cd3a278869ea812244030d@haskell.org> Message-ID: <061.c77edf49b92d23a5e6a8034fc921f8ea@haskell.org> #10812: High memory usage ---------------------------------+----------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Description changed by danilo2: Old description: > Hello, lets consider following program: > > {{{ > {-# LANGUAGE NoMonomorphismRestriction #-} > > import System.Mem.Weak > import Control.Concurrent > import System.Mem > > data Tst a = Tst a deriving (Show, Eq) > > tst a = do > let arr = [0 .. a*a*a] > v = Tst (seq arr arr) > ptr <- mkWeakPtr v Nothing > return ptr > > main = do > ptrs <- mapM tst [1..100000000] > --performGC > --performMajorGC > --performMinorGC > threadDelay 1000000 > xr <- mapM deRefWeak ptrs > print $ length $ filter (/= Nothing) xr > > threadDelay 5000000 > > return () > }}} > > It simply creates 10 million of weak references to values of {{{Tst}}}. > These weak pointers are returned in the main function. After that we > sleep a second and ask how meany references are alive. I get the {{{0}}} > as a result here - so everything seems ok - garbage collection worked. > There is a problem though - somehow the memory was not released, because > on the second 5-second sleep the program uses over 14 Gb of RAM on my > computer. > > I'm compiling it simply with {{{ghc -O2 Main.hs}}}. I'm pretty sure this > is a bug, because such behaviour is not expected I think. New description: Hello, lets consider following program: {{{ {-# LANGUAGE NoMonomorphismRestriction #-} import System.Mem.Weak import Control.Concurrent import System.Mem data Tst a = Tst a deriving (Show, Eq) tst a = do let arr = [0 .. a*a*a] v = Tst (seq arr arr) ptr <- mkWeakPtr v Nothing return ptr main = do ptrs <- mapM tst [1..100000000] --performGC --performMajorGC --performMinorGC threadDelay 1000000 xr <- mapM deRefWeak ptrs print $ length $ filter (/= Nothing) xr threadDelay 5000000 return () }}} It simply creates 10 million of weak references to values of {{{Tst}}}. These weak pointers are returned in the main function. After that we sleep a second and ask how meany references are alive. I get the {{{0}}} as a result here - so everything seems ok - garbage collection worked. There is a problem though - somehow the memory was not released, because during the last 5-second sleep the program uses over 14 Gb of RAM on my computer. I'm compiling it simply with {{{ghc -O2 Main.hs}}}. I'm pretty sure this is a bug, because such behaviour is not expected I think. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 29 18:18:43 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Aug 2015 18:18:43 -0000 Subject: [GHC] #10812: High memory usage In-Reply-To: <046.80aa46a375cd3a278869ea812244030d@haskell.org> References: <046.80aa46a375cd3a278869ea812244030d@haskell.org> Message-ID: <061.4acc9ceb9701578577f5af72fe246693@haskell.org> #10812: High memory usage ---------------------------------+----------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by bgamari): The problem is that the GC isn't being performed after traversing `xr`; if you manually insert a `performGc` before the `threadDelay` then you will find things behave as you expect. For the record, the given test seems to behave as expected on my machine. My testing methodology was rather crude, {{{ $ ghc -O Test.hs; ./Test & pid=$!; while true; do cat /proc/$pid/stat >> stat; sleep 0.01; done $ ipython --pylab >>> a = genfromtxt('stat') >>> vsize = a[:,22] # see proc(5) >>> plot(vsize / 1024**2) >>> ylabel('vsize / megabytes') >>> xlabel('something approximating time') }}} With `[1..10000000]` `vsize` peaked around 1.8GB around 3 seconds after starting the process. With the testcase provided above `vsize` remained at this peak for the remaining duration of the program. With a manual `performGC` after the traversal, however, it dropped to essentially zero around a second after plateauing. It stayed there for the rest of the execution. The moral of the story is if you want the runtime to GC at a given point, you must tell it. GC occurs due to allocation. Given that there is essentially no allocation after the traversal it isn't terribly surprising that no GC is occurring. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 29 18:18:56 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Aug 2015 18:18:56 -0000 Subject: [GHC] #10812: High memory usage In-Reply-To: <046.80aa46a375cd3a278869ea812244030d@haskell.org> References: <046.80aa46a375cd3a278869ea812244030d@haskell.org> Message-ID: <061.d5ef3d05c9ee9e52e1942bcdf11830bf@haskell.org> #10812: High memory usage ---------------------------------+----------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: wontfix | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 29 21:00:11 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Aug 2015 21:00:11 -0000 Subject: [GHC] #10813: No symlinks after install. Message-ID: <044.30de17d6e49ba7b96d0d9ce49250ac2e@haskell.org> #10813: No symlinks after install. -------------------------------------+------------------------------------- Reporter: NormH | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 7.10.2 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Installing GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- After having run the installer represented by file: Haskell Platform 7.10.2-a 64bit-signed.pkg (which I found here: https://www.haskell.org/platform) ("openssl md5 Has*" yields 436e5370acfefbfe4cf7e3bc0a2fc56b) The Installer says "The installation was successful". I am looking at the page: file:///Library/Haskell/doc/start.html That page says: Executables are symlinked in /usr/bin and should be available in any shell. I can find no new symlinks there. Perhaps I am merely don't know what to look for. The documentation does not tell me what to expect that I can see. The shell command "ls -ltr /usr/bin" shows nothing newer than July; this is late August. Command "ls /usr/bin/gh* /usr/bin/has*" yields only "hash". "ls /Library/Frameworks/GHC.framework" and "/Library/Haskell" are populated. I am running OS X 10.11 (beta). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 29 21:27:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Aug 2015 21:27:36 -0000 Subject: [GHC] #10813: No symlinks after install. In-Reply-To: <044.30de17d6e49ba7b96d0d9ce49250ac2e@haskell.org> References: <044.30de17d6e49ba7b96d0d9ce49250ac2e@haskell.org> Message-ID: <059.da1302962047782d43c0fa7a76e5c133@haskell.org> #10813: No symlinks after install. -------------------------------------+------------------------------------- Reporter: NormH | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: ghc-pkg | Version: 7.10.2 Resolution: invalid | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => invalid Comment: I'm sorry, but this is not the Haskell Platform issue tracker. Please report your problem here: https://github.com/haskell/haskell- platform/issues. (It's unfortunate that the Haskell Platform website didn't tell you this) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 29 21:44:28 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Aug 2015 21:44:28 -0000 Subject: [GHC] #10813: No symlinks after install. In-Reply-To: <044.30de17d6e49ba7b96d0d9ce49250ac2e@haskell.org> References: <044.30de17d6e49ba7b96d0d9ce49250ac2e@haskell.org> Message-ID: <059.c3eecb6444626c8af40161ade5ba9ade@haskell.org> #10813: No symlinks after install. -------------------------------------+------------------------------------- Reporter: NormH | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: ghc-pkg | Version: 7.10.2 Resolution: invalid | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Replying to [comment:1 thomie]: > (It's unfortunate that the Haskell Platform website didn't tell you this) I opened https://github.com/haskell/haskell-platform/issues/204 for this: . -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 29 22:34:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Aug 2015 22:34:14 -0000 Subject: [GHC] #10812: High memory usage In-Reply-To: <046.80aa46a375cd3a278869ea812244030d@haskell.org> References: <046.80aa46a375cd3a278869ea812244030d@haskell.org> Message-ID: <061.432e2ed3d19cd2dd3372bbb1407a5a52@haskell.org> #10812: High memory usage ---------------------------------+----------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: wontfix | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by danilo2): Hello @bgamari! Thank you for your response :) I've tried running {{{performGC}}} manually (please look again in my code - I've tried all the versions above). Unfortunately even running it, nothing happens, the program consumes the same amount of RAM unless it terminates. Additionally I've tried such variant: {{{ {-# LANGUAGE NoMonomorphismRestriction #-} import System.Mem.Weak import Control.Concurrent import System.Mem data Tst a = Tst a deriving (Show, Eq) tst a = do let arr = [0 .. a*a*a] v = Tst (seq arr arr) ptr <- mkWeakPtr v Nothing return ptr xmain = do ptrs <- mapM tst [1..100000000] performGC threadDelay 1000000 xr <- mapM deRefWeak ptrs print $ length $ filter (/= Nothing) xr threadDelay 10000000 return () main = do print "A" xmain print "B" xmain }}} I wanted to check how the program behaves when allocating again some resources, so I run {{{xmain}}} two times. What's interesting is that the memory is still not released and during second execution the amount of RAM used by it exceeds 21 Gb - so it allocates further resources. So I've got 2 questions: 1) Maybe it is Mac OS X related bug? 2) You've told me that GC is performed only when memory is allocated, so when we are performing {{{MapM}}} ten million times, allocating each time a small chunk of memory (and returning weak pointers only), shouldn't the GC be called at last several times then? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 29 22:34:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Aug 2015 22:34:41 -0000 Subject: [GHC] #10812: High memory usage In-Reply-To: <046.80aa46a375cd3a278869ea812244030d@haskell.org> References: <046.80aa46a375cd3a278869ea812244030d@haskell.org> Message-ID: <061.c8fd730243b378a4a9fdbf74c077b564@haskell.org> #10812: High memory usage ---------------------------------+----------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Changes (by danilo2): * status: closed => new * resolution: wontfix => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 30 01:19:07 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Aug 2015 01:19:07 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.7a63f9dd2010268dc0f9300e85e82d41@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D910, | Phab:D1073 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * differential: Phab:D1073 => Phab:D910, Phab:D1073 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 30 10:42:13 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Aug 2015 10:42:13 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.283bded1cbb80af4de88047f1b32615e@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D910, | Phab:D1073, Phab:D1133 -------------------------------------+------------------------------------- Changes (by simonmar): * differential: Phab:D910, Phab:D1073 => Phab:D910, Phab:D1073, Phab:D1133 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 30 11:13:09 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Aug 2015 11:13:09 -0000 Subject: [GHC] #10812: High memory usage after performing GC (was: High memory usage) In-Reply-To: <046.80aa46a375cd3a278869ea812244030d@haskell.org> References: <046.80aa46a375cd3a278869ea812244030d@haskell.org> Message-ID: <061.4d336d510354865b779f3048a6d9ccda@haskell.org> #10812: High memory usage after performing GC ---------------------------------+----------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 30 11:15:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Aug 2015 11:15:10 -0000 Subject: [GHC] #10062: Codegen on sequential FFI calls is not very good In-Reply-To: <049.b796a4f17cfdd37dfc8152ae0e3bc180@haskell.org> References: <049.b796a4f17cfdd37dfc8152ae0e3bc180@haskell.org> Message-ID: <064.f88af4772cf7508fa251d3925e0f13f6@haskell.org> #10062: Codegen on sequential FFI calls is not very good -------------------------------------+------------------------------------- Reporter: chadaustin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > I'm writing a library for efficiently building up a byte buffer. The > fastest approach I've found is via FFI, with restricted effects like ST. > It's over twice as fast as ByteString Builder. > > Consider this example API usage: https://github.com/chadaustin/buffer- > builder/blob/6bd0a39c56f63ab751faf29f9784ac87d52638be/bench/Bench.hs#L46 > > It compiles into an instruction sequence containing direct, sequenced FFI > calls. For example, the last three calls work out to: > > addq $8,%rsp > movq %rbx,%rdi > movq 72(%rsp),%rax > movq %rax,%rsi > subq $8,%rsp > movl $0,%eax > call bw_append_bsz > > addq $8,%rsp > movq %rbx,%rdi > movl $35,%esi > subq $8,%rsp > movl $0,%eax > call bw_append_byte > > addq $8,%rsp > movq %rbx,%rdi > movq 64(%rsp),%rax > movq %rax,%rsi > subq $8,%rsp > movl $0,%eax > call bw_append_bsz > > I don't know why rsp is being changed so much. I also can't explain the > assignment to eax before the call. (It should also be xorl eax,eax, I > would think.) > > To my reading, the above instruction sequence could be reduced to: > > movq %rbx,%rdi > movq 64(%rsp),%rsi > call bw_append_bsz > > movq %rbx,%rdi > movl $35,%esi > call bw_append_byte > > movq %rbx,%rdi > movq 56(%rsp),%rsi > call bw_append_bsz > > To reproduce, check out git at github.com:chadaustin/buffer-builder.git at > revision 6bd0a39c56f63ab751faf29f9784ac87d52638be > > cabal configure --enable-benchmarks > cabal bench > > And then look at the ./dist/build/bench/bench-tmp/bench/Bench.dump-asm > file. > > This is specifically on OS X 64-bit with GHC 7.8.3, but I saw similar > code generation on GHC 7.6 on Linux 64-bit. New description: I'm writing a library for efficiently building up a byte buffer. The fastest approach I've found is via FFI, with restricted effects like ST. It's over twice as fast as ByteString Builder. Consider this example API usage: https://github.com/chadaustin/buffer- builder/blob/6bd0a39c56f63ab751faf29f9784ac87d52638be/bench/Bench.hs#L46 It compiles into an instruction sequence containing direct, sequenced FFI calls. For example, the last three calls work out to: {{{ addq $8,%rsp movq %rbx,%rdi movq 72(%rsp),%rax movq %rax,%rsi subq $8,%rsp movl $0,%eax call bw_append_bsz addq $8,%rsp movq %rbx,%rdi movl $35,%esi subq $8,%rsp movl $0,%eax call bw_append_byte addq $8,%rsp movq %rbx,%rdi movq 64(%rsp),%rax movq %rax,%rsi subq $8,%rsp movl $0,%eax call bw_append_bsz }}} I don't know why `rsp` is being changed so much. I also can't explain the assignment to `eax` before the call. (It should also be `xorl eax,eax`, I would think.) To my reading, the above instruction sequence could be reduced to: {{{ movq %rbx,%rdi movq 64(%rsp),%rsi call bw_append_bsz movq %rbx,%rdi movl $35,%esi call bw_append_byte movq %rbx,%rdi movq 56(%rsp),%rsi call bw_append_bsz }}} To reproduce, check out `git at github.com:chadaustin/buffer-builder.git` at revision 6bd0a39c56f63ab751faf29f9784ac87d52638be {{{ cabal configure --enable-benchmarks cabal bench }}} And then look at the `./dist/build/bench/bench-tmp/bench/Bench.dump-asm` file. This is specifically on OS X 64-bit with GHC 7.8.3, but I saw similar code generation on GHC 7.6 on Linux 64-bit. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 30 11:58:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Aug 2015 11:58:40 -0000 Subject: [GHC] #10787: Incorrect code example for pattern synonyms In-Reply-To: <049.ebf5abc73106dd0931b303481127fab7@haskell.org> References: <049.ebf5abc73106dd0931b303481127fab7@haskell.org> Message-ID: <064.d5e4be2e2c3ec06437d826c90d5e533d@haskell.org> #10787: Incorrect code example for pattern synonyms -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Documentation | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1191 -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => patch * differential: => Phab:D1191 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 30 16:46:11 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Aug 2015 16:46:11 -0000 Subject: [GHC] #10787: Incorrect code example for pattern synonyms In-Reply-To: <049.ebf5abc73106dd0931b303481127fab7@haskell.org> References: <049.ebf5abc73106dd0931b303481127fab7@haskell.org> Message-ID: <064.ec8856fba4a10d685af8e4299412695e@haskell.org> #10787: Incorrect code example for pattern synonyms -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Documentation | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1191 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"12098c2e70b2a432f4ed675ed72b53a396cb2842/ghc" 12098c2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="12098c2e70b2a432f4ed675ed72b53a396cb2842" Fix typo in pattern synonym documentation. `MkT` is the name of the constructor whilst `T` is the name of the type. Reviewers: bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1191 GHC Trac Issues: #10787 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 30 19:07:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Aug 2015 19:07:00 -0000 Subject: [GHC] #10368: STM test failing on Armhf/Linux In-Reply-To: <044.6c875c75185feb19cd9d136bb8014898@haskell.org> References: <044.6c875c75185feb19cd9d136bb8014898@haskell.org> Message-ID: <059.8097b90661c0049f7cd45b510abffa8b@haskell.org> #10368: STM test failing on Armhf/Linux -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: #7815 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by fryguybob): Noting here, an easier way forward is to use the coarse-grain implementation instead and make sure that the lock acquire and release of the global lock are correct for ARM. This should be good for a couple of cores. Note that an important performance bug to fix would be the one addressed here: https://github.com/fryguybob/ghc/commit/6e1df4eac2c2806b87561c5d3876ba4b50e5af70 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 30 21:51:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Aug 2015 21:51:32 -0000 Subject: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) In-Reply-To: <051.8a467503f7e6e3ea87602b7d1c1e067f@haskell.org> References: <051.8a467503f7e6e3ea87602b7d1c1e067f@haskell.org> Message-ID: <066.0c32bce164b1b7a0061d984c42f2c484@haskell.org> #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 6.10.2 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9256 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * cc: ekmett (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 31 00:33:12 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Aug 2015 00:33:12 -0000 Subject: [GHC] #7259: Eta expansion of products in System FC In-Reply-To: <046.eb91fb12bdf35396d79679c78f7a6c38@haskell.org> References: <046.eb91fb12bdf35396d79679c78f7a6c38@haskell.org> Message-ID: <061.853da6d926db4e08db0dcf466e830321@haskell.org> #7259: Eta expansion of products in System FC -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by josef): * cc: josef.svenningsson@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 31 04:08:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Aug 2015 04:08:05 -0000 Subject: [GHC] #10814: Eliminate some ambiguity for IsString [a] Message-ID: <044.3cb71730365e3c9cf61989f2886ab212@haskell.org> #10814: Eliminate some ambiguity for IsString [a] -------------------------------------+------------------------------------- Reporter: dolio | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Core | Version: 7.10.2 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The libraries list resolved to make a modification to the `String` instance for `IsString` to resolve certain ambiguous cases. One example is: {{{#!hs "hello" ++ " world" }}} This case can be resolved by making the instance: {{{#!hs instance (a ~ Char) => IsString [a] where ... }}} rather than: {{{#!hs instance IsString [Char] where ... }}} as the former matches only based on the head being `[a]`, and subsequently determines `a ~ Char`, rather than only matching when other factors cause the head to be fully resolved to `[Char]`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 31 04:23:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Aug 2015 04:23:34 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.09efedd77a1223631e603fcd545f2e0f@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192 -------------------------------------+------------------------------------- Changes (by niteria): * differential: Phab:D910, Phab:D1073, Phab:D1133 => Phab:D910, Phab:D1073, Phab:D1133, Phab:D1192 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 31 04:26:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Aug 2015 04:26:50 -0000 Subject: [GHC] #10814: Eliminate some ambiguity for IsString [a] In-Reply-To: <044.3cb71730365e3c9cf61989f2886ab212@haskell.org> References: <044.3cb71730365e3c9cf61989f2886ab212@haskell.org> Message-ID: <059.fee41d04c02b89292d26a5bdf47a6a7d@haskell.org> #10814: Eliminate some ambiguity for IsString [a] -------------------------------------+------------------------------------- Reporter: dolio | Owner: dolio Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by dolio): * owner: ekmett => dolio -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 31 06:13:53 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Aug 2015 06:13:53 -0000 Subject: [GHC] #7259: Eta expansion of products in System FC In-Reply-To: <046.eb91fb12bdf35396d79679c78f7a6c38@haskell.org> References: <046.eb91fb12bdf35396d79679c78f7a6c38@haskell.org> Message-ID: <061.f72efd918a5f753da6c3db8bda97d4f4@haskell.org> #7259: Eta expansion of products in System FC -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Josef and I chatted about this ticket at HIW today. Now that `Any` is moved out of the way, it seems quite possible to revisit this. Shouldn't be too hard. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 31 06:25:59 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Aug 2015 06:25:59 -0000 Subject: [GHC] #10815: Need more kind inference in associated type instances Message-ID: <047.d8bc1a4461bf2f49e829557a2b73313c@haskell.org> #10815: Need more kind inference in associated type instances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE DataKinds, PolyKinds, TypeFamilies #-} module Bug where import Data.Proxy class kproxy ~ 'KProxy => C (kproxy :: KProxy k) where type F (a :: k) instance C ('KProxy :: KProxy Bool) where type F a = Int }}} I get {{{ Type indexes must match class instance head Found ?k? but expected ?Bool? In the type instance declaration for ?F? In the instance declaration for ?C (KProxy :: KProxy Bool)? }}} But the kind of `a` should really be known to be `Bool`. This ticket is broken out from comment:3:ticket:9063, which was evidently not addressed when fixing that ticket. Patch coming soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 31 06:31:54 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Aug 2015 06:31:54 -0000 Subject: [GHC] #10816: Fixity declaration for associated type rejected Message-ID: <047.cd9a1f02ca3266d044f12741b664719c@haskell.org> #10816: Fixity declaration for associated type rejected -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE TypeOperators, TypeFamilies #-} module Bug where class C a where type a # b infix 4 # }}} I get {{{ Bug.hs:7:11: ?#? is not a (visible) method of class ?C? }}} But it really should just assign a fixity to the type `#`. It works if the fixity declaration is outside of the class. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 31 06:37:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Aug 2015 06:37:29 -0000 Subject: [GHC] #10817: Looping default associated type family without UndecidableInstances Message-ID: <047.64ffaf6cb4d5ab1829ed952b25df0d19@haskell.org> #10817: Looping default associated type family without UndecidableInstances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE TypeFamilies #-} module Bug where import Data.Proxy class C a where type F a type F a = F a instance C Bool x :: Proxy (F Bool) x = Proxy }}} GHC just loops. Setting a low `-ftype-function-depth` doesn't help. I actually don't terribly mind the looping (although aborting with an overflow would be better). But I don't like that it's possible without `UndecidableInstances` in sight. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 31 06:41:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Aug 2015 06:41:18 -0000 Subject: [GHC] #10818: GHC 7.10.2 takes much longer to compile some packages Message-ID: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> #10818: GHC 7.10.2 takes much longer to compile some packages -------------------------------------+------------------------------------- Reporter: kazu- | Owner: yamamoto | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- If we compile the iproute package by GHC, GHC 7.10.2 take much longer than GHC 7.8.4. See the report from Travis CI: https://travis-ci.org/kazu-yamamoto/iproute/builds/77427248 I can reproduce this on my local MacBookAir: - GHC 7.8.4: cabal build 8.81s user 0.94s system 103% cpu 9.430 total - GHC 7.10.2: cabal build 37.86s user 3.49s system 98% cpu 42.066 total -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 31 08:07:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Aug 2015 08:07:40 -0000 Subject: [GHC] #10818: GHC 7.10.2 takes much longer to compile some packages In-Reply-To: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> References: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> Message-ID: <067.7df88bfc54e786565b366e8b24cea62b@haskell.org> #10818: GHC 7.10.2 takes much longer to compile some packages -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * priority: normal => high * failure: None/Unknown => Compile-time performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 31 08:59:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Aug 2015 08:59:31 -0000 Subject: [GHC] #10792: Bounded Enums [minBound..maxBound] produces runtime error In-Reply-To: <056.73eb9fb152f83711a842e4b0cfcb2567@haskell.org> References: <056.73eb9fb152f83711a842e4b0cfcb2567@haskell.org> Message-ID: <071.cf730957a05e6a424cb4e824b08c974c@haskell.org> #10792: Bounded Enums [minBound..maxBound] produces runtime error -------------------------------------+------------------------------------- Reporter: | Owner: ekmett AlexanderThiemann | Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by AlexanderThiemann): I've tried to consistently reproduce the bug but it only happens in maybe 5-10% of all runs (see also https://github.com/agrafix/Spock/issues/44#issuecomment-134899484 ). Since removing the minBound..maxBound calls the bug seems to have gone away. Is there any non deterministic behavior in Enums/Bounded? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 31 14:56:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Aug 2015 14:56:05 -0000 Subject: [GHC] #10368: STM test failing on Armhf/Linux In-Reply-To: <044.6c875c75185feb19cd9d136bb8014898@haskell.org> References: <044.6c875c75185feb19cd9d136bb8014898@haskell.org> Message-ID: <059.d5a3b57532234781112a3bea0521fbbe@haskell.org> #10368: STM test failing on Armhf/Linux -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: #7815 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): I'm not sure what has changed, but I am now unable to get any of my ARM boards to fail this test reliably with the fine grained locks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 31 15:11:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Aug 2015 15:11:39 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.bb3cc5b9bf663a3d50de0573dd6a8929@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192 -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"10a07753ff4ac0c1285454567c926d580d0f0470/ghc" 10a0775/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="10a07753ff4ac0c1285454567c926d580d0f0470" Anchor type family instances deterministically Summary: This is very similar to D1073. It makes type family instances to be attached to a binding with a least `OccName`, therefore not depending on `Unique` ordering. Test Plan: * this makes `Language.Haskell.Exts.SrcLoc` deterministic * ./validate Reviewers: simonmar, austin, bgamari, simonpj Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1192 GHC Trac Issues: #4012 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 31 15:24:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Aug 2015 15:24:24 -0000 Subject: [GHC] #10818: GHC 7.10.2 takes much longer to compile some packages In-Reply-To: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> References: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> Message-ID: <067.fd6aead7d2b69481db677bfea5ab37a3@haskell.org> #10818: GHC 7.10.2 takes much longer to compile some packages -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gidyn (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 31 21:38:30 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Aug 2015 21:38:30 -0000 Subject: [GHC] #10793: Incorrect blocked on MVar detection In-Reply-To: <051.7658851bb71506c4b1bae1ee7211ff06@haskell.org> References: <051.7658851bb71506c4b1bae1ee7211ff06@haskell.org> Message-ID: <066.87e73bfa206b784418c160d2c58a556b@haskell.org> #10793: Incorrect blocked on MVar detection -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: wontfix | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by NeilMitchell): I still don't understand, most likely because my understanding of what causes a BlockedIndefinitelyOnMVar exception is probably wrong. Is there a good link to the current semantics? And what actually triggers such an exception? Ditto for NonTermination. (And separately, should such pointers be added to the Exception docs?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 31 22:59:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Aug 2015 22:59:39 -0000 Subject: [GHC] #10413: Incorrect offsets for array size indexing In-Reply-To: <048.fb282c815f959019fb8541a09f28e9ea@haskell.org> References: <048.fb282c815f959019fb8541a09f28e9ea@haskell.org> Message-ID: <063.9bd6776666c729779b3a03893b021f59@haskell.org> #10413: Incorrect offsets for array size indexing -------------------------------------+------------------------------------- Reporter: fryguybob | Owner: fryguybob Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by fryguybob): * owner: => fryguybob -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 31 23:12:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Aug 2015 23:12:47 -0000 Subject: [GHC] #10413: Incorrect offsets for array size indexing In-Reply-To: <048.fb282c815f959019fb8541a09f28e9ea@haskell.org> References: <048.fb282c815f959019fb8541a09f28e9ea@haskell.org> Message-ID: <063.9e4419c2bbd9092eab001b6fc61cba6a@haskell.org> #10413: Incorrect offsets for array size indexing -------------------------------------+------------------------------------- Reporter: fryguybob | Owner: fryguybob Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1194 -------------------------------------+------------------------------------- Changes (by fryguybob): * differential: => Phab:D1194 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 31 23:16:11 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Aug 2015 23:16:11 -0000 Subject: [GHC] #10815: Need more kind inference in associated type instances In-Reply-To: <047.d8bc1a4461bf2f49e829557a2b73313c@haskell.org> References: <047.d8bc1a4461bf2f49e829557a2b73313c@haskell.org> Message-ID: <062.353c0df479dfa2c2aa639715af99d204@haskell.org> #10815: Need more kind inference in associated type instances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1195 -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => patch * differential: => Phab:D1195 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 22:31:11 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 22:31:11 -0000 Subject: [GHC] #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options In-Reply-To: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> References: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> Message-ID: <062.b8e0385b5c8bea7b22ccb8cb92de278d@haskell.org> #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Seems reasonable to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 2 22:53:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Aug 2015 22:53:33 -0000 Subject: [GHC] #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options In-Reply-To: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> References: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> Message-ID: <062.06ccf2ef32463c4724f6a1d53e59cd91@haskell.org> #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9221, #8224 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * related: => #9221, #8224 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 12:54:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 12:54:08 -0000 Subject: [GHC] #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options In-Reply-To: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> References: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> Message-ID: <062.4b59cdc3fd92052c2537ebdf9e268a0f@haskell.org> #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9221, #8224 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonmar): Yes, I think this would be good. I've actually used `setNumCapabilities` and `getNumProcessors` to do this as @rrnewton suggests, but having a flag would be easier. Any takers? It's not hard. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 5 13:31:21 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Aug 2015 13:31:21 -0000 Subject: [GHC] #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options In-Reply-To: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> References: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> Message-ID: <062.a0c7ff7f23bb987df60e565705598b70@haskell.org> #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9221, #8224 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler