#8301: error BaseReg must be in a register for THREADED_RTS ----------------------------------------+----------------------------- Reporter: erikd | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Changes (by gustavold): * cc: gustavold@… (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8301#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 1 00:14:27 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 00:14:27 -0000 Subject: [GHC] #8390: regression in handling of type variables in constraints on instances which do not appear in the instance head Message-ID: <045.f7ebc1e824a1088a68849321bde868cc@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:43 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:43 -0000

#8390: regression in handling of type variables in constraints on instances which do not appear in the instance head ----------------------------+---------------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects valid program Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- ghc-7.7.20130720 (from here http://darcs.haskell.org/ghcBuilder/uploads/igloo-m/) rejects instances which work with ghc-7.6.2. {{{ {-# LANGUAGE FlexibleInstances, ImplicitParams, MultiParamTypeClasses, ScopedTypeVariables, TypeFamilies, UndecidableInstances #-} class Fun f a b where fun :: f -> a -> b instance (b ~ Int, a ~ Int) => Fun F a b where fun _ = (+1) data F = F data Compose a b = Compose a b -- ghc-7.6 version instance (Fun f b c, Fun g a b) => Fun (Compose f g) a c where fun (Compose f g) a = fun f (fun g a :: b) {- | ghc >= 7.7 accepts this second instance, which is an ugly workaround

...

...

fun (Compose F F) 2 4

unsatisfactory ghc-77 workaround:

...

...

let ?b = undefined in fun (Compose F F) 2 4

-} instance (Fun f b c, Fun g a b, ?b :: b) => Fun (Compose f g) a c where fun (Compose f g) a = fun f (fun g a `asTypeOf` ?b) }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8390 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 1 00:16:58 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 00:16:58 -0000 Subject: [GHC] #8390: regression in handling of type variables in constraints on instances which do not appear in the instance head In-Reply-To: <045.f7ebc1e824a1088a68849321bde868cc@haskell.org> References: <045.f7ebc1e824a1088a68849321bde868cc@haskell.org> Message-ID: <060.33f5063f7f0255eb6a0e3345b3e2f4a2@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:43 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:43 -0000

#8390: regression in handling of type variables in constraints on instances which do not appear in the instance head ----------------------------------------------+---------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by aavogt): If it helps, the error with ghc-7.7 is: {{{ inf.hs:26:10: Warning: Could not deduce (Fun g a b0) arising from the ambiguity check for an instance declaration from the context (Fun f b c, Fun g a b) bound by an instance declaration: (Fun f b c, Fun g a b) => Fun (Compose f g) a c at inf.hs:26:10-56 The type variable ?b0? is ambiguous In the ambiguity check for: forall f g a c b. (Fun f b c, Fun g a b) => Fun (Compose f g) a c In the instance declaration for ?Fun (Compose f g) a c? Ok, modules loaded: Main. }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8390#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 1 01:45:54 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 01:45:54 -0000 Subject: [GHC] #8380: Numerous testsuite failures on ARM due to missing mkJumpToAddr In-Reply-To: <046.6822dd2c7a2b1392cbd1b6deb902b274@haskell.org> References: <046.6822dd2c7a2b1392cbd1b6deb902b274@haskell.org> Message-ID: <061.08caa0750c57109074ef99b02d9c24d5@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:44 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:44 -0000

#8380: Numerous testsuite failures on ARM due to missing mkJumpToAddr -------------------------------------+--------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: patch Operating System: Unknown/Multiple | Architecture: arm Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+--------------------------- Changes (by bgamari): * owner: => bgamari -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8380#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 1 02:02:18 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 02:02:18 -0000 Subject: [GHC] #8380: Numerous testsuite failures on ARM due to missing mkJumpToAddr In-Reply-To: <046.6822dd2c7a2b1392cbd1b6deb902b274@haskell.org> References: <046.6822dd2c7a2b1392cbd1b6deb902b274@haskell.org> Message-ID: <061.1c2b5429b6dba9d2ec7a5278338e5f52@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:44 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:44 -0000

#8380: Numerous testsuite failures on ARM due to missing mkJumpToAddr -------------------------------------+--------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: patch Operating System: Unknown/Multiple | Architecture: arm Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+--------------------------- Comment (by bgamari): As thoughtpolice pointed out in #ghc, it appears the libffi actually already takes care of icache flushing. I've updated the patch set to reflect this. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8380#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 1 02:24:17 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 02:24:17 -0000 Subject: [GHC] #8391: FunDeps coverage condition check failure with PolyKinds Message-ID: <047.b2bf3b0730ed8141c814d71a4a379642@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:44 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:44 -0000

From ghc-devs at haskell.org Tue Oct 1 04:45:53 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 04:45:53 -0000 Subject: [GHC] #8134: ghc enters a loop while building 7.6.3 for

#8391: FunDeps coverage condition check failure with PolyKinds ----------------------------+---------------------------------------------- Reporter: sbarclay | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects valid program Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: #8356 | ----------------------------+---------------------------------------------- The following code: {{{ #!haskell {-# LANGUAGE FunctionalDependencies, FlexibleInstances, UndecidableInstances, TypeFamilies, PolyKinds #-} module FunDepsIssue where type Foo a = a class Foo a ~ b => Bar a b | a -> b instance Foo a ~ b => Bar a b }}} results in: {{{ Illegal instance declaration for ?Bar k a b? Multiple uses of this instance may be inconsistent with the functional dependencies of the class. In the instance declaration for ?Bar a b? }}} This appears to be a regression from 7.6.3, where it compiles OK. The same error occurs when the type synonym is replaced with a type family (which is the case I was originally interested in) or a type constructor like `Data.Proxy`, as long as it's poly-kinded it seems. So the following cases also fail to compile: {{{ #!haskell type family Foo (a :: k) :: * type family Foo (a :: *) :: k type family Foo (a :: k) :: k type family Foo (a :: k) :: k' }}} Looking through the source code, I think that the issue is that the coverage condition check doesn't close over kind variables, when it compares the vars on each side of the functional dependency. But `Foo a` has a hidden kind variable, so the l.h. varset `{a}` is insufficient to fix `b` using `Foo a ~ b`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8391 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler powerpc64 platform. In-Reply-To: <043.0289be94f89f3f22e5a1a6cc61dcce1b@haskell.org> References: <043.0289be94f89f3f22e5a1a6cc61dcce1b@haskell.org> Message-ID: <058.28924e61f5d4687e5eb9aef24d4c9f49@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:44 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:44 -0000 #8134: ghc enters a loop while building 7.6.3 for powerpc64 platform. -------------------------------------+----------------------------- Reporter: k0da | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.3 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+----------------------------- Comment (by oliver.batchelor): I can confirm this occurs for me on an opensuse ppc64 box, too. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8134#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 1 05:24:28 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 05:24:28 -0000 Subject: [GHC] #8390: regression in handling of type variables in constraints on instances which do not appear in the instance head In-Reply-To: <045.f7ebc1e824a1088a68849321bde868cc@haskell.org> References: <045.f7ebc1e824a1088a68849321bde868cc@haskell.org> Message-ID: <060.b6a2bebfbfac01793ef65732ff313896@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:45 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:45 -0000

#8390: regression in handling of type variables in constraints on instances which do not appear in the instance head ----------------------------------------------+---------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by aavogt): While Compose may not be so interesting, the same thing prevents HList from having both a single class for polymorphic functions (Fun above) and having higher-order functions that work for some instances of that class (ones like F). Some faking can be done by having some associated types for Fun to calculate the argument from the result type etc. But that is uglier (see attached inf2). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8390#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 1 07:48:18 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 07:48:18 -0000 Subject: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper In-Reply-To: <044.f94356cf74dc801e8fb7c76a9eaeb24d@haskell.org> References: <044.f94356cf74dc801e8fb7c76a9eaeb24d@haskell.org> Message-ID: <059.612bd57d9142067278c8cf2dd2cc543a@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:45 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:45 -0000

#5928: INLINABLE fails to specialize in presence of simple wrapper -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by liyang): * cc: hackage.haskell.org@? (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/5928#comment:20 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 1 08:33:16 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 08:33:16 -0000 Subject: [GHC] #8129: Constraint solver panic due to derived type function equality In-Reply-To: <049.06f6d1838f85c9d46949cd56075105a5@haskell.org> References: <049.06f6d1838f85c9d46949cd56075105a5@haskell.org> Message-ID: <064.609d1f4169f23cea440258502cd6ae2b@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:45 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:45 -0000

#8129: Constraint solver panic due to derived type function equality -------------------------------------------------+------------------------- Reporter: adamgundry | Owner: Type: bug | Status: Priority: high | closed Component: Compiler (Type checker) | Milestone: Resolution: fixed | Version: 7.7 Operating System: Unknown/Multiple | Keywords: Type of failure: Compile-time crash | Architecture: Test Case: | Unknown/Multiple indexed_types/should_fail/T8129 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:d6b61598e3543b5445590193fe67a5c3c1930117/testsuite]: {{{ #!CommitTicketReference repository="testsuite" revision="d6b61598e3543b5445590193fe67a5c3c1930117" Fix T8129 (#8129) }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8129#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 1 08:36:35 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 08:36:35 -0000 Subject: [GHC] #8129: Constraint solver panic due to derived type function equality In-Reply-To: <049.06f6d1838f85c9d46949cd56075105a5@haskell.org> References: <049.06f6d1838f85c9d46949cd56075105a5@haskell.org> Message-ID: <064.9a062b2dce291034d8723399c3e44cfb@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:45 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:45 -0000

#8129: Constraint solver panic due to derived type function equality -------------------------------------------------+------------------------- Reporter: adamgundry | Owner: Type: bug | Status: Priority: high | closed Component: Compiler (Type checker) | Milestone: Resolution: fixed | Version: 7.7 Operating System: Unknown/Multiple | Keywords: Type of failure: Compile-time crash | Architecture: Test Case: | Unknown/Multiple indexed_types/should_fail/T8129 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by monoidal): This is due to "grep deduce T8129.trace" in Makefile. I fixed it. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8129#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 1 09:48:39 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 09:48:39 -0000 Subject: [GHC] #7753: Profiling report broken with foreign exported functions In-Reply-To: <043.cdad128df5cc1da6704a1d6046e471a1@haskell.org> References: <043.cdad128df5cc1da6704a1d6046e471a1@haskell.org> Message-ID: <058.16d34a3f704cce4e83c3d3be95181469@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:45 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:45 -0000

#7753: Profiling report broken with foreign exported functions ---------------------------------+------------------------------------ Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Profiling | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by akio): I think I know what is happening. The {{{wrapper}}} and {{{f}}} cost centres are actually placed under {{{SYSTEM}}}. I can see it by using {{{+RTS -pa}}} instead of {{{+RTS -p}}}. However {{{SYSTEM}}} is a hidden cost centre, so by default it's not included in the report, resulting in a confusing call tree. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7753#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 1 09:52:47 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 09:52:47 -0000 Subject: [GHC] #7753: Profiling report broken with foreign exported functions In-Reply-To: <043.cdad128df5cc1da6704a1d6046e471a1@haskell.org> References: <043.cdad128df5cc1da6704a1d6046e471a1@haskell.org> Message-ID: <058.4ef48701f98823ecd3444bc166b9017a@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:46 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:46 -0000

#7753: Profiling report broken with foreign exported functions ---------------------------------+------------------------------------ Reporter: akio | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Profiling | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Changes (by akio): * status: new => patch Comment: I'm not sure if this is the best way to fix it, but the attached patch improves the output; now {{{wrapper}}} and {{{f}}} are placed directly under {{{MAIN}}}, and they get {{{inherited}}} costs correctly. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7753#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 1 10:23:26 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 10:23:26 -0000 Subject: [GHC] #8254: confusing comment on allocate() In-Reply-To: <047.f2bfb1d82a66bdcef27cbf1185aab323@haskell.org> References: <047.f2bfb1d82a66bdcef27cbf1185aab323@haskell.org> Message-ID: <062.ff56cc403fec1b201b86892cfb55393f@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:46 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:46 -0000

#8254: confusing comment on allocate() --------------------------------------+------------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Documentation bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by simonmar): * status: closed => new * resolution: fixed => Comment: d85044f6b201eae0a9e453b89c0433608e0778f0 was reverted. I'll fix. This appeared because allocate() used to be called allocateLocal(). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8254#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 1 10:23:46 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 10:23:46 -0000 Subject: [GHC] #8254: confusing comment on allocate() In-Reply-To: <047.f2bfb1d82a66bdcef27cbf1185aab323@haskell.org> References: <047.f2bfb1d82a66bdcef27cbf1185aab323@haskell.org> Message-ID: <062.296866d22330e63dad385136ed17a6bd@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:46 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:46 -0000

#8254: confusing comment on allocate() --------------------------------------+------------------------------------ Reporter: rwbarton | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Documentation bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by simonmar): * owner: => simonmar * milestone: => 7.8.1 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8254#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 1 10:30:34 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 10:30:34 -0000 Subject: [GHC] #7993: ghc 7.6 (not 7.4) sometimes hangs at child process exit on s390x In-Reply-To: <047.88b56f359408533f50983a91b9a9fb88@haskell.org> References: <047.88b56f359408533f50983a91b9a9fb88@haskell.org> Message-ID: <062.d1d13673775aa1b4e51352c7fc0f9859@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:46 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:46 -0000

#7993: ghc 7.6 (not 7.4) sometimes hangs at child process exit on s390x -----------------------------------+--------------------------- Reporter: cjwatson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: Other Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+--------------------------- Comment (by simonmar): Getting a stack trace would probably help. You want to make sure that GHC itself is built with `-debug`: set `GhcDebugged=YES` in your build.mk (this will slow down the build, but you can remove it later). When the process hangs, attach to it with gdb and get a backtrace of all the threads. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7993#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 1 10:37:56 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 10:37:56 -0000 Subject: [GHC] #8377: GHCi crashes with unboxed values on 32-bit platforms In-Reply-To: <043.659c5e09852704a620211fd314f16dcf@haskell.org> References: <043.659c5e09852704a620211fd314f16dcf@haskell.org> Message-ID: <058.3a27bbd0fc221bab9acc2658c68d380f@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:46 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:46 -0000

#8377: GHCi crashes with unboxed values on 32-bit platforms ------------------------------------------+--------------------------- Reporter: akio | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: GHCi crash | Difficulty: Unknown Test Case: ghci/should_run/T8377 | Blocked By: Blocking: | Related Tickets: ------------------------------------------+--------------------------- Comment (by simonmar): Good catch. This must have broke when `StgWord` was changed to be `Word64`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8377#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 1 10:46:16 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 10:46:16 -0000 Subject: [GHC] #8279: bad alignment in code gen yields substantial perf issue In-Reply-To: <045.3fa2c6fed8a76bf664b09b6a4e78beae@haskell.org> References: <045.3fa2c6fed8a76bf664b09b6a4e78beae@haskell.org> Message-ID: <060.e20d9c3cd646b50b19ef68c8a9afaca2@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:46 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:46 -0000

#8279: bad alignment in code gen yields substantial perf issue --------------------------------------------+------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8082 --------------------------------------------+------------------------------ Comment (by simonmar): So the problem with 16-byte aligning branch targets is that many of our code blocks have a 3-word info table. We would have to pad these info tables by one word in addition to aligning to 16 bytes. That might not be too bad, but someone needs to do the measurements to see what the code size / speed tradeoff is. Also we don't necessarily want to align all our labels, because many of them are just heap-check failure targets and wouldn't benefit from aligning at all. I tend to optimise for small binary sizes because I was brought up on computers with 32K of memory and I think you should never waste a byte :-) If you think binary size can be won elsewhere, please do it :-P -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8279#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 1 10:48:43 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 10:48:43 -0000 Subject: [GHC] #7783: MultiWayIf should start a new layout In-Reply-To: <044.4f2ebc6f2a6763cb3be79faa05da1543@haskell.org> References: <044.4f2ebc6f2a6763cb3be79faa05da1543@haskell.org> Message-ID: <059.80e7e88312bad99dfa410119480c1e81@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:46 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:46 -0000

#7783: MultiWayIf should start a new layout --------------------------------------+------------------------------------ Reporter: exbb2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Parser) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #4359 --------------------------------------+------------------------------------ Comment (by Simon Marlow ): In [changeset:aab65608f9a26990b2c5083e4b65b9d1f6c9b48a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="aab65608f9a26990b2c5083e4b65b9d1f6c9b48a" Add layout to MultiWayIf (#7783) This makes it possible to write x = if | False -> if | False -> 1 | False -> 2 | True -> 3 Layout normally inserts semicolons between declarations at the same indentation level, so I added optional semicolons to the syntax for guards in MultiWayIf syntax. This is a bit of a hack, but the alternative (a special kind of layout that doesn't insert semicolons) seemed worse, or at least equally bad. }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7783#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 1 10:53:01 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 10:53:01 -0000 Subject: [GHC] #7783: MultiWayIf should start a new layout In-Reply-To: <044.4f2ebc6f2a6763cb3be79faa05da1543@haskell.org> References: <044.4f2ebc6f2a6763cb3be79faa05da1543@haskell.org> Message-ID: <059.e22880aee449ad6125fde587a0d5b945@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:46 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:46 -0000

#7783: MultiWayIf should start a new layout --------------------------------------+------------------------------------ Reporter: exbb2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler (Parser) | Version: 7.6.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #4359 --------------------------------------+------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7783#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 1 10:59:07 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 10:59:07 -0000 Subject: [GHC] #8247: Dependency tracking (--make) broken for re-exported modules In-Reply-To: <048.361775e5eb3bed132f36f1f1c494bfa1@haskell.org> References: <048.361775e5eb3bed132f36f1f1c494bfa1@haskell.org> Message-ID: <063.537e297fe4fc04b4d166e7bc730227c9@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:47 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:47 -0000

#8247: Dependency tracking (--make) broken for re-exported modules -------------------------------------+------------------------------------ Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: recomp013 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): I just added a `sleep 1` to make the test more reliable. Please re-open if you still have problems. see testsuite/b831fb94517d52681954d829c9289a8eb506b5d5 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8247#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 1 10:59:19 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 10:59:19 -0000 Subject: [GHC] #8247: Dependency tracking (--make) broken for re-exported modules In-Reply-To: <048.361775e5eb3bed132f36f1f1c494bfa1@haskell.org> References: <048.361775e5eb3bed132f36f1f1c494bfa1@haskell.org> Message-ID: <063.306550204af6938d8ac4321b9dc69e7a@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:47 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:47 -0000

#8247: Dependency tracking (--make) broken for re-exported modules -------------------------------------+------------------------------------ Reporter: heisenbug | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: recomp013 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed * milestone: => 7.8.1 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8247#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 1 11:09:05 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 11:09:05 -0000 Subject: [GHC] #8329: dmdTransformDictSelSig panic In-Reply-To: <047.c283e9e86d7f217263d707bab25fb26f@haskell.org> References: <047.c283e9e86d7f217263d707bab25fb26f@haskell.org> Message-ID: <062.427399e0c6294d80e053ab49b6e2c351@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:47 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:47 -0000

#8329: dmdTransformDictSelSig panic ---------------------------------------+----------------------------------- Reporter: monoidal | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by Simon Peyton Jones ): In [changeset:9bd366642f495fe26db261317dd416de1ff854bc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9bd366642f495fe26db261317dd416de1ff854bc" Lift an unnecessary assumption in the demand analyser (fix Trac #8329) Here's the Note about the (simple) fix. Apparently #8329 prevented all 23 packages of the Snap framework from compiling. Note [Demand transformer for a ditionary selector] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If we evaluate (op dict-expr) under demand 'd', then we can push the demand 'd' into the appropriate field of the dictionary. What *is* the appropriate field? We just look at the strictness signature of the class op, which will be something like: U(AAASAAAAA). Then replace the 'S' by the demand 'd'. For single-method classes, which are represented by newtypes the signature of 'op' won't look like U(...), so the splitProdDmd_maybe will fail. That's fine: if we are doing strictness analysis we are also doing inling, so we'll have inlined 'op' into a cast. So we can bale out in a conservative way, returning topDmdType. It is (just.. Trac #8329) possible to be running strictness analysis *without* having inlined class ops from single-method classes. Suppose you are using ghc --make; and the first module has a local -O0 flag. So you may load a class without interface pragmas, ie (currently) without an unfolding for the class ops. Now if a subsequent module in the --make sweep has a local -O flag you might do strictness analysis, but there is no inlining for the class op. This is wierd so I'm not worried about whether this optimises brilliantly; but it should not fall over. }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8329#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 1 11:09:43 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 11:09:43 -0000 Subject: [GHC] #8329: dmdTransformDictSelSig panic In-Reply-To: <047.c283e9e86d7f217263d707bab25fb26f@haskell.org> References: <047.c283e9e86d7f217263d707bab25fb26f@haskell.org> Message-ID: <062.0baaa1156510cd0ceca743e8b153a837@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:47 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:47 -0000

#8329: dmdTransformDictSelSig panic ---------------------------------------+----------------------------------- Reporter: monoidal | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by Simon Peyton Jones ): In [changeset:81d8da9bcb6348caf103b38d76423cb7d71136fa/testsuite]: {{{ #!CommitTicketReference repository="testsuite" revision="81d8da9bcb6348caf103b38d76423cb7d71136fa" Test Trac #8329 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8329#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 1 11:10:12 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 11:10:12 -0000 Subject: [GHC] #8329: dmdTransformDictSelSig panic In-Reply-To: <047.c283e9e86d7f217263d707bab25fb26f@haskell.org> References: <047.c283e9e86d7f217263d707bab25fb26f@haskell.org> Message-ID: <062.bddc92a9d0725eb2b9ec6523bafdde96@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:47 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:47 -0000

#8329: dmdTransformDictSelSig panic -------------------------------------------------+------------------------- Reporter: monoidal | Owner: Type: bug | simonpj Priority: highest | Status: Component: Compiler | closed Resolution: fixed | Milestone: Operating System: Unknown/Multiple | Version: 7.7 Type of failure: Compile-time crash | Keywords: Test Case: | Architecture: simplCore/should_compile/T8329 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * status: new => closed * testcase: => simplCore/should_compile/T8329 * resolution: => fixed -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8329#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 1 13:15:15 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 13:15:15 -0000 Subject: [GHC] #8390: regression in handling of type variables in constraints on instances which do not appear in the instance head In-Reply-To: <045.f7ebc1e824a1088a68849321bde868cc@haskell.org> References: <045.f7ebc1e824a1088a68849321bde868cc@haskell.org> Message-ID: <060.87c785d77ca5eac6ebf2a1950a0639df@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:47 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:47 -0000

#8390: regression in handling of type variables in constraints on instances which do not appear in the instance head ----------------------------------------------+---------------------------- Reporter: aavogt | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by aavogt): * status: new => closed * resolution: => invalid Comment: I found -XAllowAmbiguousTypes, added by commit 97db0edc4e637dd61ec635d1f9b6b6dd25ad890c, which allows the old behavior. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8390#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 1 14:54:25 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 14:54:25 -0000 Subject: [GHC] #8392: Suggest AllowAmbiguousTypes Message-ID: <047.260dbec4450efd89f823d0de3b069a9d@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:47 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:47 -0000

#8392: Suggest AllowAmbiguousTypes -------------------------------------------+------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- The error message I get with GHC HEAD on the example program in #8390: {{{ tf.hs:38:10: Could not deduce (Fun g a b0) arising from the ambiguity check for an instance declaration from the context (Fun f b c, Fun g a b) bound by an instance declaration: (Fun f b c, Fun g a b) => Fun (Compose f g) a c at tf.hs:38:10-56 The type variable ?b0? is ambiguous In the ambiguity check for: forall f g a c b. (Fun f b c, Fun g a b) => Fun (Compose f g) a c In the instance declaration for ?Fun (Compose f g) a c? }}} could perhaps benefit from an appended line: {{{ (To defer this ambiguity check to use sites, enable AllowAmbiguousTypes) }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8392 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 1 15:55:06 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 15:55:06 -0000 Subject: [GHC] #8359: ConstraintKinds require UndecidableInstances when it doesn't need it In-Reply-To: <050.d99b55b3f8e4de99877837036bb5fc1b@haskell.org> References: <050.d99b55b3f8e4de99877837036bb5fc1b@haskell.org> Message-ID: <065.d12fd3143f04336331ff7ffbeab19792@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:47 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:47 -0000

#8359: ConstraintKinds require UndecidableInstances when it doesn't need it ----------------------------------------------+---------------------------- Reporter: thomaseding | 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: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by unknown ): In [changeset:4407614cb19a65ddb2f9ede4778a0b47396f8ec9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4407614cb19a65ddb2f9ede4778a0b47396f8ec9" Look inside tuple predicates when checking instance declaration contexts This fixes Trac #8359 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8359#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 1 15:55:08 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 15:55:08 -0000 Subject: [GHC] #8356: Strangeness with FunDeps In-Reply-To: <042.e3202299281602befe025c334253735b@haskell.org> References: <042.e3202299281602befe025c334253735b@haskell.org> Message-ID: <057.0963b995737cddeebda5ebc37b7dbcb9@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:47 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:47 -0000

#8356: Strangeness with FunDeps ----------------------------------------------+---------------------------- Reporter: ksf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by unknown ): In [changeset:bceeb0167804e3325b48d4b360fddd68e29735a2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bceeb0167804e3325b48d4b360fddd68e29735a2" Improve error reporting of fundep coverage condition failure This modest improvement is motivated by Trac #8356 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8356#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 1 16:03:20 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 16:03:20 -0000 Subject: [GHC] #8392: Suggest AllowAmbiguousTypes In-Reply-To: <047.260dbec4450efd89f823d0de3b069a9d@haskell.org> References: <047.260dbec4450efd89f823d0de3b069a9d@haskell.org> Message-ID: <062.aec7c54bc209ed3c854e99e9ae71381a@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:48 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:48 -0000

#8392: Suggest AllowAmbiguousTypes --------------------------------------------+------------------------------ Reporter: rwbarton | Owner: monoidal Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by monoidal): * owner: => monoidal -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8392#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 1 17:02:00 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 17:02:00 -0000 Subject: [GHC] #8393: hsc2hs copies #define/#undef directives to generated .hs file when cross-compiling Message-ID: <047.c681d6d31d973e801b05913ab74a7713@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:48 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:48 -0000

#8393: hsc2hs copies #define/#undef directives to generated .hs file when cross- compiling ------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- See summary. This causes a cross-compilation of ghc to fail while building GHC/Stack.hsc from libraries/base, because base.cabal no longer specifies `extensions: CPP` as of dfb52c3d5. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8393 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 1 17:05:01 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 17:05:01 -0000 Subject: [GHC] #8393: hsc2hs copies #define/#undef directives to generated .hs file when cross-compiling In-Reply-To: <047.c681d6d31d973e801b05913ab74a7713@haskell.org> References: <047.c681d6d31d973e801b05913ab74a7713@haskell.org> Message-ID: <062.63db5405a202fb96ee85b4c988e686d3@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:48 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:48 -0000

#8393: hsc2hs copies #define/#undef directives to generated .hs file when cross- compiling -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: rwbarton Type: bug | Status: patch Priority: normal | Milestone: Component: hsc2hs | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by rwbarton): * status: new => patch -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8393#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 1 17:08:16 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 17:08:16 -0000 Subject: [GHC] #8393: hsc2hs copies #define/#undef directives to generated .hs file when cross-compiling In-Reply-To: <047.c681d6d31d973e801b05913ab74a7713@haskell.org> References: <047.c681d6d31d973e801b05913ab74a7713@haskell.org> Message-ID: <062.138bbda0f8a158e5646371585f5e8d73@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:48 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:48 -0000

#8393: hsc2hs copies #define/#undef directives to generated .hs file when cross- compiling -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: rwbarton Type: bug | Status: patch Priority: normal | Milestone: Component: hsc2hs | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Description changed by hvr: Old description:

See summary. This causes a cross-compilation of ghc to fail while building GHC/Stack.hsc from libraries/base, because base.cabal no longer specifies `extensions: CPP` as of dfb52c3d5.

New description: See summary. This causes a cross-compilation of ghc to fail while building GHC/Stack.hsc from libraries/base, because base.cabal no longer specifies `extensions: CPP` as of [dfb52c3d5/base]. -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8393#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 1 17:11:16 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 17:11:16 -0000 Subject: [GHC] #8276: Building Haddock documentation panics with perf build on x86_64 Linux In-Reply-To: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> References: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> Message-ID: <063.7df3f3defef416f9fe9c594630f7c108@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:48 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:48 -0000

#8276: Building Haddock documentation panics with perf build on x86_64 Linux ---------------------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Documentation | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by tibbe): * cc: johan.tibell@? (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8276#comment:25 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 1 17:27:36 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 17:27:36 -0000 Subject: [GHC] #8359: ConstraintKinds require UndecidableInstances when it doesn't need it In-Reply-To: <050.d99b55b3f8e4de99877837036bb5fc1b@haskell.org> References: <050.d99b55b3f8e4de99877837036bb5fc1b@haskell.org> Message-ID: <065.b397e41afab926e93337bea8f2b11379@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:48 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:48 -0000

#8359: ConstraintKinds require UndecidableInstances when it doesn't need it ----------------------------------------------+---------------------------- Reporter: thomaseding | 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: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by Simon Peyton Jones ): In [changeset:eb135c315b6070ec677a4ca049c462e912002d7b/testsuite]: {{{ #!CommitTicketReference repository="testsuite" revision="eb135c315b6070ec677a4ca049c462e912002d7b" Test Trac #8359 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8359#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 1 17:29:02 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 17:29:02 -0000 Subject: [GHC] #8359: ConstraintKinds require UndecidableInstances when it doesn't need it In-Reply-To: <050.d99b55b3f8e4de99877837036bb5fc1b@haskell.org> References: <050.d99b55b3f8e4de99877837036bb5fc1b@haskell.org> Message-ID: <065.a70ea5041ce803a96e59f93e52fa4430@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:48 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:48 -0000

#8359: ConstraintKinds require UndecidableInstances when it doesn't need it ----------------------------------------------+---------------------------- Reporter: thomaseding | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: polykinds/T8359 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by simonpj): * status: new => closed * testcase: => polykinds/T8359 * resolution: => fixed Comment: Thanks for pointing this out. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8359#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 1 17:33:18 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 17:33:18 -0000 Subject: [GHC] #8356: Strangeness with FunDeps In-Reply-To: <042.e3202299281602befe025c334253735b@haskell.org> References: <042.e3202299281602befe025c334253735b@haskell.org> Message-ID: <057.9ed25d24525ccae6841fa3e7a9d2ecd0@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:48 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:48 -0000

#8356: Strangeness with FunDeps -------------------------------------------------+------------------------- Reporter: ksf | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: Resolution: fixed | Version: 7.7 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple typecheck/should_fail/tcfail170 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * status: new => closed * testcase: => typecheck/should_fail/tcfail170 * resolution: => fixed Comment: Error message improved. Here it is for `tcfail170`: {{{ tcfail170.hs:7:10: Illegal instance declaration for ?C [p] [q]? The coverage condition fails in class ?C? for functional dependency: ?a -> b? Reason: lhs type ?[p]? does not deternine rhs type ?[q]? In the instance declaration for ?C [p] [q]? }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8356#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 1 18:34:10 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Oct 2013 18:34:10 -0000 Subject: [GHC] #6166: Performance regression in mwc-random since 7.0.x In-Reply-To: <042.f838154dee2d7e7158fd4f9ebd6ea928@haskell.org> References: <042.f838154dee2d7e7158fd4f9ebd6ea928@haskell.org> Message-ID: <057.bf81f40a956f0f3c5d3a14ad6cfe7810@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:49 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:49 -0000

#6166: Performance regression in mwc-random since 7.0.x --------------------------------------------+------------------------------ Reporter: bos | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Khudyakov): Another simplification {{{ {-# LANGUAGE BangPatterns #-} import qualified Data.Vector.Unboxed as I import Data.Vector.Unboxed ((!)) import Control.Monad main :: IO () main = replicateM_ (200*1000) (return $! standard) standard :: Double -- Removing or replacing with NOINLINE returns perfomance to normal {-# INLINE standard #-} standard = blocks ! 0 where blocks :: I.Vector Double blocks = I.cons 0.123 $ I.unfoldrN 130 go (T f) where go q@(T a) = Just (log (exp a), q) {-# NOINLINE blocks #-} r,f :: Double r = 3.442619855899 -- replacing f with constant return perfomance to normal -- f = 2.669629083880923e-3 f = exp (-0.5 * r * r) -- replacing data with newtype returns performance to normal data T = T {-# UNPACK #-} !Double }}} Problem is visible at the core level. Code is compiled down to the something similar to following pseudocode: {{{ loop i = if i /= 0 then evaluate (blocks ! 0) >> loop (i-1) else return () }}} blocks array is inlied despite being marked as NOINLINE and is evaluated on each iteration so performance is abysmal. When small chages to the program are made it's not inlined and evaluated only once. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/6166#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 00:14:35 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 00:14:35 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.5b6b979e4f57fb6bc9fffc38a8f51052@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:49 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:49 -0000

#8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by kazu-yamamoto): I did not notice your previous comment. Sorry for the delay. I tried 8266_proper_fix.patch and confirmed that it works well. 8266_fix.patch: {{{ % otool -L libffi.dylib libffi.dylib: /Users/kazu/work/ghc/libffi/build/inst/lib/libffi.6.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0) }}} 8266_proper_fix.patch: {{{ % otool -L libffi.dylib libffi.dylib: @rpath/rts-1.0/libffi.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0) }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8266#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 00:27:32 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 00:27:32 -0000 Subject: [GHC] #8394: T7478 fails on i386 Linux with "unresolvable R_386_32 relocation" from ld Message-ID: <047.84247404c5743a6b21344dd8163dc5f7@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:49 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:49 -0000

#8394: T7478 fails on i386 Linux with "unresolvable R_386_32 relocation" from ld ----------------------------+--------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.7 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 8294 | ----------------------------+--------------------------------- Much like #8294. Here is the error messages from the debug output: {{{ /usr/bin/ld: dynamic variable `base_GHCziBase_zdfMonadIO_closure' is zero size /usr/bin/ld: dynamic variable `ghczmprim_GHCziTuple_Z0T_closure' is zero size /usr/bin/ld: dynamic variable `base_GHCziTopHandler_runMainIO_closure' is zero size /usr/bin/ld: C.o(.text+0x59): unresolvable R_386_32 relocation against symbol `base_GHCziBase_zdfMonadIO_closure' /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8394 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 00:35:58 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 00:35:58 -0000 Subject: [GHC] #8394: T7478 fails on i386 Linux with "unresolvable R_386_32 relocation" from ld In-Reply-To: <047.84247404c5743a6b21344dd8163dc5f7@haskell.org> References: <047.84247404c5743a6b21344dd8163dc5f7@haskell.org> Message-ID: <062.30a4aeeecbf61a76fac0391dcece4b0f@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:49 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:49 -0000

#8394: T7478 fails on i386 Linux with "unresolvable R_386_32 relocation" from ld ---------------------------------+--------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8294 ---------------------------------+--------------------------- Changes (by rwbarton): * related: 8294 => #8294 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8394#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 01:15:15 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 01:15:15 -0000 Subject: [GHC] #8395: Various testsuite fixes for cross-compilation/i386/etc. Message-ID: <047.7fc31e71e82f9b3201d752e81a2124df@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:49 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:49 -0000

#8395: Various testsuite fixes for cross-compilation/i386/etc. ------------------------------+--------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------+--------------------------------- First patch is to libraries/base, other three are to testsuite. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8395 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 01:16:26 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 01:16:26 -0000 Subject: [GHC] #8395: Various testsuite fixes for cross-compilation/i386/etc. In-Reply-To: <047.7fc31e71e82f9b3201d752e81a2124df@haskell.org> References: <047.7fc31e71e82f9b3201d752e81a2124df@haskell.org> Message-ID: <062.1f2f98ea737a2280f460fab2fa9bc787@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:49 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:49 -0000

#8395: Various testsuite fixes for cross-compilation/i386/etc. ---------------------------------+--------------------------- Reporter: rwbarton | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+--------------------------- Changes (by rwbarton): * status: new => patch -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8395#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 03:34:58 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 03:34:58 -0000 Subject: [GHC] #8256: adding locality levels to prefetch# and friends In-Reply-To: <045.bc455c21650626f3242606c828908318@haskell.org> References: <045.bc455c21650626f3242606c828908318@haskell.org> Message-ID: <060.8d3c5eb8353bcb87d1b75fe9b96be2da@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:49 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:49 -0000

#8256: adding locality levels to prefetch# and friends -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: task | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8252 ,#8107 -------------------------------------+------------------------------------ Comment (by carter): ok great! will this make it into 7.8? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8256#comment:31 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 03:45:17 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 03:45:17 -0000 Subject: [GHC] #8396: cleanup / refactor native code gens Message-ID: <045.aa7cf1c57555c9884c0054e57028458c@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:49 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:49 -0000

#8396: cleanup / refactor native code gens ----------------------------------------+---------------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: None/Unknown Blocked By: | Test Case: Related Tickets: #8299 , #8287 ,#8272 | Blocking: ----------------------------------------+---------------------------------- the native code gen could use some cleanup / love. 1. Catchup with feature parity of the llvm a. this includes adding SIMD support on applicable native code gen architectures, starting with x86_64 2. make it easier to extend / modify experiment with the native code gen 3. make it easier to add new primops (maybe even a magic inline asm primop?!) 4. other things i'm overlooking right now this also overlaps with a number of related tickets i've been adding to trac. a more ambitious strategic goal that won't be the initial goal, that simon marlow suggested when i chatted with him at ICFP, is to make the native code gen codebase a sort of "mini-llvm". I think thats a bit ambitious for the near term, but maybe thats the point on the horizon we may want to aim towards. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8396 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 05:45:23 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 05:45:23 -0000 Subject: [GHC] #7028: incorrect link paths for in mac os x after install In-Reply-To: <050.5a49a7d43a2082b8077d439d3e55628b@haskell.org> References: <050.5a49a7d43a2082b8077d439d3e55628b@haskell.org> Message-ID: <065.08be4155f8f34f9f402f51565aaeba5c@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:49 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:49 -0000

#7028: incorrect link paths for in mac os x after install ------------------------------------------+-------------------------------- Reporter: andykitchen | Owner: leroux Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Build System | Version: 7.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Installing GHC failed | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Changes (by leroux): * owner: => leroux -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7028#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 05:48:05 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 05:48:05 -0000 Subject: [GHC] #7028: incorrect link paths for in mac os x after install In-Reply-To: <050.5a49a7d43a2082b8077d439d3e55628b@haskell.org> References: <050.5a49a7d43a2082b8077d439d3e55628b@haskell.org> Message-ID: <065.6a525ece1e97bccf4a932d3828f30d4c@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:49 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:49 -0000

#7028: incorrect link paths for in mac os x after install ------------------------------------------+-------------------------------- Reporter: andykitchen | Owner: leroux Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.1 Component: Build System | Version: 7.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Installing GHC failed | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Changes (by leroux): * status: new => infoneeded Comment: Are you still experiencing these issues with HEAD or 7.6 binary dist? It could be helpful if you would test it with a setup similar the one before. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7028#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 05:54:38 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 05:54:38 -0000 Subject: [GHC] #3725: Annotations not written to interface files In-Reply-To: <041.dfa4280aa188470f7b07eff4da2beab3@haskell.org> References: <041.dfa4280aa188470f7b07eff4da2beab3@haskell.org> Message-ID: <056.c700d99b2d817f95f8563e79d4f48dde@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:49 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:49 -0000

#3725: Annotations not written to interface files -------------------------------+------------------------------------------- Reporter: rl | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: 7867 | -------------------------------+------------------------------------------- Comment (by Austin Seipp ): In [changeset:bc8a5e14881f0754991390fbc0c37f928887f5eb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bc8a5e14881f0754991390fbc0c37f928887f5eb" Persist annotations to interface files (#3725) Authored-by: Gergely Risko <gergely at risko.hu> Signed-off-by: Austin Seipp <austin at well-typed.com> }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/3725#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 05:54:39 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 05:54:39 -0000 Subject: [GHC] #8283: utils/fingerprint/fingerprint.py doesn't work on Windows In-Reply-To: <046.25b2c96356daabaeccc622e6ddf85249@haskell.org> References: <046.25b2c96356daabaeccc622e6ddf85249@haskell.org> Message-ID: <061.69b3d3e62681c0a746a583ed07967cbb@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:50 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:50 -0000

#8283: utils/fingerprint/fingerprint.py doesn't work on Windows -------------------------------+------------------------------------------- Reporter: schyler | Owner: leroux Type: bug | Status: patch Priority: low | Milestone: Component: Build | Version: 7.7 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Easy (less than 1 hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------+------------------------------------------- Comment (by Austin Seipp ): In [changeset:70ccf23f7e2f67c395be4cb87c8f4a26dd65918d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="70ccf23f7e2f67c395be4cb87c8f4a26dd65918d" fingerprint.py: Invoke 'perl' manually (#8283) This fixes the fingerprint script on windows, since we can't rely on using '#!/usr/bin/perl' Signed-off-by: Austin Seipp <austin at well-typed.com> }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8283#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 05:54:40 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 05:54:40 -0000 Subject: [GHC] #8340: support for generating annotations from TH In-Reply-To: <044.200a45cd5d51f3df399e26cac81cba5d@haskell.org> References: <044.200a45cd5d51f3df399e26cac81cba5d@haskell.org> Message-ID: <059.6a7eaa633d5e74460094017df1569ab9@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:50 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:50 -0000

#8340: support for generating annotations from TH -------------------------------+------------------------------------------- Reporter: errge | Owner: Type: feature | Status: patch request | Milestone: 7.8.1 Priority: normal | Version: 7.7 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: 7867 | -------------------------------+------------------------------------------- Comment (by Austin Seipp ): In [changeset:627d1e008cbe4d9318b2466394420a968d1659da/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="627d1e008cbe4d9318b2466394420a968d1659da" Add TH support for annotations (#8340) Authored-by: Gergely Risko <gergely at risko.hu> Signed-off-by: Austin Seipp <austin at well-typed.com> }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8340#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 05:54:40 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 05:54:40 -0000 Subject: [GHC] #8256: adding locality levels to prefetch# and friends In-Reply-To: <045.bc455c21650626f3242606c828908318@haskell.org> References: <045.bc455c21650626f3242606c828908318@haskell.org> Message-ID: <060.b6a35fb45696a41ee488d8a54eb8be99@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:50 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:50 -0000

#8256: adding locality levels to prefetch# and friends -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: task | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8252 ,#8107 -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:fd74014079f14bd3ab50e328e52c44ef97d40e05/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fd74014079f14bd3ab50e328e52c44ef97d40e05" Add support for prefetch with locality levels. This patch adds support for several new primitive operations which support using processor-specific instructions to help guide data and cache locality decisions. We have levels ranging from [0..3] For LLVM, we generate llvm.prefetch intrinsics at the proper locality level (similar to GCC.) For x86 we generate prefetch{NTA, t2, t1, t0} instructions. On SPARC and PowerPC, the locality levels are ignored. This closes #8256. Authored-by: Carter Tazio Schonwald Signed-off-by: Austin Seipp <austin at well-typed.com> }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8256#comment:32 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 05:55:27 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 05:55:27 -0000 Subject: [GHC] #8393: hsc2hs copies #define/#undef directives to generated .hs file when cross-compiling In-Reply-To: <047.c681d6d31d973e801b05913ab74a7713@haskell.org> References: <047.c681d6d31d973e801b05913ab74a7713@haskell.org> Message-ID: <062.c978b068104c22c37ccbd1e2e5903e89@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:50 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:50 -0000

#8393: hsc2hs copies #define/#undef directives to generated .hs file when cross- compiling -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: rwbarton Type: bug | Status: patch Priority: normal | Milestone: Component: hsc2hs | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:47bd048f243fd010e9d8e05039405263ef30ff54/testsuite]: {{{ #!CommitTicketReference repository="testsuite" revision="47bd048f243fd010e9d8e05039405263ef30ff54" Mark those tests which depend on libraries not built when cross-compiling Issue #8393 Signed-off-by: Austin Seipp <austin at well-typed.com> }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8393#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 05:55:27 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 05:55:27 -0000 Subject: [GHC] #8393: hsc2hs copies #define/#undef directives to generated .hs file when cross-compiling In-Reply-To: <047.c681d6d31d973e801b05913ab74a7713@haskell.org> References: <047.c681d6d31d973e801b05913ab74a7713@haskell.org> Message-ID: <062.73d654a2b9a4e1762cdaacfaf2f212a9@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:50 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:50 -0000

#8393: hsc2hs copies #define/#undef directives to generated .hs file when cross- compiling -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: rwbarton Type: bug | Status: patch Priority: normal | Milestone: Component: hsc2hs | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:47189a3c391c9d3d75d530de2ca7a645b67d78b1/testsuite]: {{{ #!CommitTicketReference repository="testsuite" revision="47189a3c391c9d3d75d530de2ca7a645b67d78b1" Skip integerGmpInternals in ghci (no unboxed tuples) Issue #8393 Signed-off-by: Austin Seipp <austin at well-typed.com> }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8393#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 05:55:28 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 05:55:28 -0000 Subject: [GHC] #8393: hsc2hs copies #define/#undef directives to generated .hs file when cross-compiling In-Reply-To: <047.c681d6d31d973e801b05913ab74a7713@haskell.org> References: <047.c681d6d31d973e801b05913ab74a7713@haskell.org> Message-ID: <062.7d0f9739142911186e260ac0dc50cb97@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:50 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:50 -0000

#8393: hsc2hs copies #define/#undef directives to generated .hs file when cross- compiling -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: rwbarton Type: bug | Status: patch Priority: normal | Milestone: Component: hsc2hs | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:881038a70cfd1e5dbd50050465c5af5b7fd8c969/testsuite]: {{{ #!CommitTicketReference repository="testsuite" revision="881038a70cfd1e5dbd50050465c5af5b7fd8c969" Add 32-bit output for T7919 Issue #8393 Signed-off-by: Austin Seipp <austin at well-typed.com> }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8393#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 05:55:28 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 05:55:28 -0000 Subject: [GHC] #8256: adding locality levels to prefetch# and friends In-Reply-To: <045.bc455c21650626f3242606c828908318@haskell.org> References: <045.bc455c21650626f3242606c828908318@haskell.org> Message-ID: <060.fddd9b5027bdccb0ae7db10c3912fb19@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:50 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:50 -0000

#8256: adding locality levels to prefetch# and friends -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: task | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8252 ,#8107 -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:14b14399f1b5189e9d18c9ddc9c6909c781af4af/testsuite]: {{{ #!CommitTicketReference repository="testsuite" revision="14b14399f1b5189e9d18c9ddc9c6909c781af4af" Add tests for prefetch primops (#8256) Authored-by: Carter Tazio Schonwald Signed-off-by: Austin Seipp <austin at well-typed.com> }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8256#comment:33 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 05:56:32 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 05:56:32 -0000 Subject: [GHC] #3725: Annotations not written to interface files In-Reply-To: <041.dfa4280aa188470f7b07eff4da2beab3@haskell.org> References: <041.dfa4280aa188470f7b07eff4da2beab3@haskell.org> Message-ID: <056.0c2d50e10b40e5d62e3a609edd423edc@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:51 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:51 -0000

#3725: Annotations not written to interface files -------------------------------+------------------------------------------- Reporter: rl | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: 7867 | -------------------------------+------------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/3725#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 05:57:07 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 05:57:07 -0000 Subject: [GHC] #8343: Interrupting readProcess doesn't work In-Reply-To: <043.84e4225491946531b278e642d5caeade@haskell.org> References: <043.84e4225491946531b278e642d5caeade@haskell.org> Message-ID: <058.9b6369555929cc5813000c4e16380232@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:51 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:51 -0000

#8343: Interrupting readProcess doesn't work ------------------------------------------------+-------------------------- Reporter: akio | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/process | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: tests/T8343 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: #5766 ------------------------------------------------+-------------------------- Changes (by thoughtpolice): * status: patch => closed * testcase: => tests/T8343 * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8343#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 05:58:19 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 05:58:19 -0000 Subject: [GHC] #8283: utils/fingerprint/fingerprint.py doesn't work on Windows In-Reply-To: <046.25b2c96356daabaeccc622e6ddf85249@haskell.org> References: <046.25b2c96356daabaeccc622e6ddf85249@haskell.org> Message-ID: <061.00b135a52bb9781b2393a461471437a9@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:51 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:51 -0000

#8283: utils/fingerprint/fingerprint.py doesn't work on Windows -------------------------------+------------------------------------------- Reporter: schyler | Owner: leroux Type: bug | Status: closed Priority: low | Milestone: Component: Build | Version: 7.7 System | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Easy (less than 1 hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------+------------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8283#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 05:58:36 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 05:58:36 -0000 Subject: [GHC] #8395: Various testsuite fixes for cross-compilation/i386/etc. In-Reply-To: <047.7fc31e71e82f9b3201d752e81a2124df@haskell.org> References: <047.7fc31e71e82f9b3201d752e81a2124df@haskell.org> Message-ID: <062.be5d8896442f09732dd3c157f0fefc4e@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:51 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:51 -0000

#8395: Various testsuite fixes for cross-compilation/i386/etc. ---------------------------------+--------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+--------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8395#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 05:59:30 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 05:59:30 -0000 Subject: [GHC] #8340: support for generating annotations from TH In-Reply-To: <044.200a45cd5d51f3df399e26cac81cba5d@haskell.org> References: <044.200a45cd5d51f3df399e26cac81cba5d@haskell.org> Message-ID: <059.12b56066bef5e785dec35c27c3332947@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:51 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:51 -0000

#8340: support for generating annotations from TH -------------------------------+------------------------------------------- Reporter: errge | Owner: Type: feature | Status: closed request | Milestone: 7.8.1 Priority: normal | Version: 7.7 Component: Compiler | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: 7867 | -------------------------------+------------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8340#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 05:59:58 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 05:59:58 -0000 Subject: [GHC] #8256: adding locality levels to prefetch# and friends In-Reply-To: <045.bc455c21650626f3242606c828908318@haskell.org> References: <045.bc455c21650626f3242606c828908318@haskell.org> Message-ID: <060.4baf2d7a074a6b9f064eaf82dd4df4fb@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:51 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:51 -0000

#8256: adding locality levels to prefetch# and friends -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: task | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8252 ,#8107 -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8256#comment:34 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 06:01:05 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 06:01:05 -0000 Subject: [GHC] #8393: hsc2hs copies #define/#undef directives to generated .hs file when cross-compiling In-Reply-To: <047.c681d6d31d973e801b05913ab74a7713@haskell.org> References: <047.c681d6d31d973e801b05913ab74a7713@haskell.org> Message-ID: <062.4e38e520597f9468484727cf6e4d066f@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:51 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:51 -0000

#8393: hsc2hs copies #define/#undef directives to generated .hs file when cross- compiling -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: rwbarton Type: bug | Status: closed Priority: normal | Milestone: Component: hsc2hs | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, although I totally botched the commit references... {{{ commit 4a0f67704d89712f8493a0c7eccffa9243d6ef09 Author: Reid Barton <rwbarton at gmail.com> Date: Tue Oct 1 13:02:26 2013 -0400 Don't emit #define/#undef in generated .hs files ... just like they aren't emitted in the ordinary case; see outTokenHs in C.hs. Closes #8393. Signed-off-by: Austin Seipp <austin at well-typed.com> }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8393#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 06:14:43 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 06:14:43 -0000 Subject: [GHC] #7971: doesDirectoryExist description differs from its behavior In-Reply-To: <042.6f607706a307cc93df3ea11c23f7bbaf@haskell.org> References: <042.6f607706a307cc93df3ea11c23f7bbaf@haskell.org> Message-ID: <057.828a2e98f820006a3f68776294b07dbd@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:51 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:51 -0000

#7971: doesDirectoryExist description differs from its behavior ------------------------------------------------+-------------------------- Reporter: dsf | Owner: Type: bug | bgamari Priority: normal | Status: closed Component: libraries/directory | Milestone: Resolution: fixed | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7971#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 06:46:53 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 06:46:53 -0000 Subject: [GHC] #2184: if findExecutable finds a file that matchs the argument, check if it is an executable In-Reply-To: <043.14945e7e7a44f91d6d7e77f4c5d2fcfb@haskell.org> References: <043.14945e7e7a44f91d6d7e77f4c5d2fcfb@haskell.org> Message-ID: <058.3ee8dfd09584d7a607036a3a0f6e215b@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:51 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:51 -0000

#2184: if findExecutable finds a file that matchs the argument, check if it is an executable -------------------------------------+------------------------------------- Reporter: iago | Owner: leroux Type: bug | Status: patch Priority: normal | Milestone: 7.6.2 Component: | Version: 6.8.2 libraries/directory | Keywords: findExecutable Resolution: | check executable Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by leroux): * priority: lowest => normal -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/2184#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 08:31:46 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 08:31:46 -0000 Subject: [GHC] #8256: adding locality levels to prefetch# and friends In-Reply-To: <045.bc455c21650626f3242606c828908318@haskell.org> References: <045.bc455c21650626f3242606c828908318@haskell.org> Message-ID: <060.9445fe9d9e5ec19186e15aa2f525b694@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:51 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:51 -0000

#8256: adding locality levels to prefetch# and friends -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: task | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8252 ,#8107 -------------------------------------+------------------------------------ Comment (by simonpj): Great stuff. Questions about the patch: * The primops are all marked `can_fail = True`. Could there be some words of documentation to explain why? I recall scratching my head over the can-fai-ness of primops before, so documenting the reasoning is a Good Thing. * Would it be possible to include in the Haddock comments in `primops.txt.pp` a URL where one can read more about the prefetch instructions and "locality levels"? I know that URLs go out of date, but a start would be useful. Perhaps with some keywords from that web page that might be a starting point for a subsequent search if the URL went stale. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8256#comment:35 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 10:35:28 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 10:35:28 -0000 Subject: [GHC] #8387: View patterns + pattern bindings: finnicky about scoping In-Reply-To: <049.80a7a96a249f935479042170f7e059ae@haskell.org> References: <049.80a7a96a249f935479042170f7e059ae@haskell.org> Message-ID: <064.beded76d5f59ea2b786e67ca1e2fcc7b@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:52 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:52 -0000

#8387: View patterns + pattern bindings: finnicky about scoping ----------------------------------------------+---------------------------- Reporter: tinctorius | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by tinctorius): But they are not mutually recursive. The view pattern binding depends on the function binding, but not the other way around. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8387#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 10:47:58 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 10:47:58 -0000 Subject: [GHC] #8391: FunDeps coverage condition check failure with PolyKinds In-Reply-To: <047.b2bf3b0730ed8141c814d71a4a379642@haskell.org> References: <047.b2bf3b0730ed8141c814d71a4a379642@haskell.org> Message-ID: <062.568268847bcd45cb27498dca1b4398f9@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:52 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:52 -0000

#8391: FunDeps coverage condition check failure with PolyKinds ----------------------------------------------+---------------------------- Reporter: sbarclay | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8356 ----------------------------------------------+---------------------------- Comment (by simonpj): Good catch. Patch coming. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8391#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 11:01:19 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 11:01:19 -0000 Subject: [GHC] #7783: MultiWayIf should start a new layout In-Reply-To: <044.4f2ebc6f2a6763cb3be79faa05da1543@haskell.org> References: <044.4f2ebc6f2a6763cb3be79faa05da1543@haskell.org> Message-ID: <059.9b84db140b02ab1fe087bac4009c643a@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:52 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:52 -0000

#7783: MultiWayIf should start a new layout --------------------------------------+------------------------------------ Reporter: exbb2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Parser) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #4359 --------------------------------------+------------------------------------ Changes (by simonpj): * cc: simonmar (added) * status: closed => new * resolution: fixed => Comment: Simon, would it be possible to document the design in the user manual? For example, is it now possible to explain it by saying that a multi-way 'if' is a layout herald, so that your example behaves thus? {{{ x = if { | False -> if { | False -> 1 ; | False -> 2 } ; | True -> 3 } }}} Am I allowed to put the braces and semicolons in myself? Does the close brace get put in just before the first token to the left of the initial "|"? Thanks Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7783#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 11:05:38 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 11:05:38 -0000 Subject: [GHC] #8392: Suggest AllowAmbiguousTypes In-Reply-To: <047.260dbec4450efd89f823d0de3b069a9d@haskell.org> References: <047.260dbec4450efd89f823d0de3b069a9d@haskell.org> Message-ID: <062.b9eb3cb2778c8c7af8b0700b021afb63@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:52 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:52 -0000

#8392: Suggest AllowAmbiguousTypes --------------------------------------------+------------------------------ Reporter: rwbarton | Owner: monoidal Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): Actually I'm in the area so I can do this. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8392#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 11:15:19 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 11:15:19 -0000 Subject: [GHC] #8392: Suggest AllowAmbiguousTypes In-Reply-To: <047.260dbec4450efd89f823d0de3b069a9d@haskell.org> References: <047.260dbec4450efd89f823d0de3b069a9d@haskell.org> Message-ID: <062.76dff9feab315190ea8c2bb72471bdb2@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:52 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:52 -0000

#8392: Suggest AllowAmbiguousTypes --------------------------------------------+------------------------------ Reporter: rwbarton | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by monoidal): * owner: monoidal => simonpj Comment: Simon: I'm passing to you. It's trivial to edit the error message in TcValidity.checkAmbiguity. However, this program {{{ f :: Bool ~ Int => () f = () }}} gives then {{{ Couldn't match type ?Bool? with ?Int? Inaccessible code in the type signature for f :: Bool ~ Int => () To defer this ambiguity check to use sites, enable AllowAmbiguousTypes In the ambiguity check for: Bool ~ Int => () In the type signature for ?f?: f :: Bool ~ Int => () }}} and enabling AllowAmbiguousTypes merely changes it to {{{ Couldn't match type ?Bool? with ?Int? Inaccessible code in the type signature for f :: Bool ~ Int => () }}} So ambiguity check is done before checking inaccessible code, and it might be better to change this order. I don't know if this is simple or has any side effects though. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8392#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 12:14:26 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 12:14:26 -0000 Subject: [GHC] #8387: View patterns + pattern bindings: finnicky about scoping In-Reply-To: <049.80a7a96a249f935479042170f7e059ae@haskell.org> References: <049.80a7a96a249f935479042170f7e059ae@haskell.org> Message-ID: <064.2d9216338ab483e356917fafe8e5b15b@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:52 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:52 -0000

#8387: View patterns + pattern bindings: finnicky about scoping ----------------------------------------------+---------------------------- Reporter: tinctorius | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by simonpj): I remember this as being very fiddly, so I opted for a simple solution. It's hard to motivate fancy footwork in the compiler without having some pretty compelling use-cases that motivate it. If you (and preferably a bunch of others) have really run up against this restriction in a big way, please do describe the situation, and why the workarounds are unsatisfactory. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8387#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 12:35:10 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 12:35:10 -0000 Subject: [GHC] #8397: reify annotations in TH Message-ID: <044.a4a47bd65a3e3433fc8157425376cea6@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:52 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:52 -0000

#8397: reify annotations in TH -------------------------------------------+------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: 7867 -------------------------------------------+------------------------------- For the use-case detailed in #7867, this patch adds annotation reification to TH. This may be useful as a simpler approach for other cases too, where the whole power GHC API is not needed. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8397 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 12:36:51 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 12:36:51 -0000 Subject: [GHC] #8397: reify annotations in TH In-Reply-To: <044.a4a47bd65a3e3433fc8157425376cea6@haskell.org> References: <044.a4a47bd65a3e3433fc8157425376cea6@haskell.org> Message-ID: <059.5e6111cedf5a6928a24e1f52eecac348@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:52 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:52 -0000

#8397: reify annotations in TH -------------------------------+------------------------------------------- Reporter: errge | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: 7867 | -------------------------------+------------------------------------------- Changes (by errge): * status: new => patch -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8397#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 13:24:15 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 13:24:15 -0000 Subject: [GHC] #8398: reify module list in TH Message-ID: <044.b09c2294dcb548cfe3feed4a7ba7decf@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:53 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:53 -0000

#8398: reify module list in TH -------------------------------------------+------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: #8337 | Test Case: | Blocking: 7867 -------------------------------------------+------------------------------- This patch is for the use-case detailed in #7867. The added Q monad method provides the ability to get a list of module names in a format that is compatible with the module annotation reification in #8337. The patch contains a helper method that depends on #8337, so that should be applied first. If this is problematic, it's easy to separate this patch into one that doesn't depend on #8337 and an other that does. Then we can add the latter later. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8398 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 13:25:35 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 13:25:35 -0000 Subject: [GHC] #8398: reify module list in TH In-Reply-To: <044.b09c2294dcb548cfe3feed4a7ba7decf@haskell.org> References: <044.b09c2294dcb548cfe3feed4a7ba7decf@haskell.org> Message-ID: <059.1ed79eacabc97e6f5a4e271f325d030c@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:53 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:53 -0000

#8398: reify module list in TH -------------------------------+------------------------------------------- Reporter: errge | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: #8337 Test Case: | Blocking: 7867 | -------------------------------+------------------------------------------- Changes (by errge): * status: new => patch -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8398#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 14:09:41 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 14:09:41 -0000 Subject: [GHC] #7867: Allow template-haskell to communicate with itself between compilation units through the interface file In-Reply-To: <044.7393523543fe94ac1b36b652004b6974@haskell.org> References: <044.7393523543fe94ac1b36b652004b6974@haskell.org> Message-ID: <059.da0a41c9f6970328c64d9517c0732701@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:53 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:53 -0000

#7867: Allow template-haskell to communicate with itself between compilation units through the interface file --------------------------+------------------------------------------------ Reporter: errge | Owner: Type: | Status: patch feature request | Milestone: 7.8.1 Priority: | Version: 7.6.3 normal | Keywords: Component: | Architecture: Unknown/Multiple Template Haskell | Difficulty: Easy (less than 1 hour) Resolution: | Blocked By: 3725, 8337, 8340, 8397, 8398 Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | --------------------------+------------------------------------------------ Changes (by errge): * status: new => patch * difficulty: Unknown => Easy (less than 1 hour) * milestone: => 7.8.1 Comment: 2 of 5 of the patches is already merged and the functionality in the rest of the 3 covers this ticket fully. Changing milestone to 7.8.1 and difficulty to easy, action to patch. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7867#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 16:40:55 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 16:40:55 -0000 Subject: [GHC] #8276: Building Haddock documentation panics with perf build on x86_64 Linux In-Reply-To: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> References: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> Message-ID: <063.90c1500649ede7815605a4348f3d1627@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:53 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:53 -0000

#8276: Building Haddock documentation panics with perf build on x86_64 Linux ---------------------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Documentation | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by schell): I'm also seeing this issue, and it was fixed by using the workaround listed in the description. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8276#comment:26 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 18:42:23 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 18:42:23 -0000 Subject: [GHC] #8399: Of Bird tacks and non-blank blank lines Message-ID: <049.fbd5d4dac09e7c6b91d1e23d5e132151@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:53 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:53 -0000

#8399: Of Bird tacks and non-blank blank lines --------------------------+------------------------------------------------ Reporter: | Owner: tinctorius | Status: new Type: bug | Milestone: Priority: low | Version: 7.6.3 Component: | Operating System: Unknown/Multiple Compiler | Type of failure: GHC accepts invalid program Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ {{{

main :: IO () \begin{code} \end{code} main = print "Hello world!" }}}

According to the Haskell 1.2 report, code in Bird tacks must be hugged by blank lines (or file borders), to catch unintended use. The above should be _rejected_ during the unlit phase. However, because GHC's `unlit` thinks lines with `\begin{code}` and `\end{code}` are blank lines, the above is _accepted_. I believe this is an error. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8399 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 19:18:21 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 19:18:21 -0000 Subject: [GHC] #8287: exploring calling convention changes and related engineering for 7.10 In-Reply-To: <045.594cdade97652c9633f43b7996da7568@haskell.org> References: <045.594cdade97652c9633f43b7996da7568@haskell.org> Message-ID: <060.306218f3d52fdaa483956a3ca314259f@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:53 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:53 -0000

#8287: exploring calling convention changes and related engineering for 7.10 -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: task | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Rocket Science Test Case: | Blocked By: 8299 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rwbarton): I did a port of ghc to "real x32" with the following characteristics: * produces x32 executables (these are 32-bit ELF files containing x86-64 object code and relocations, that use the x32 versions of system calls) * in particular, the entire address space of the process lives below 4GB * executables (and object files loaded by ghci) must be mapped below 2GB to avoid over/underflow in x86-64 rip-relative addressing, but the heap can use the full remaining space below 4GB (untested) * dynamic Haskell libraries are not yet implemented * Int is 32 bits, as is Addr# * heap layout is just like on i386: everything on the heap is 4-byte aligned and pointer tagging uses two bits * now with integer-gmp, using 64-bit limbs! * features a fairly small number of bizarre testsuite segfaults and other errors Effectively, it is like i386, but faster (**much** faster when doing large Integer computations due to being able to do 64-bit arithmetic, but still often faster when not), and with more crashes (but those could presumably be sorted out) and a more awkward system library situation (there is no libx32gmp10 package yet on Ubuntu, so I have to set LD_LIBRARY_PATH when running ghc's x32 executables). I attached nofib results comparing amd64 vs. x32 and i686 vs. x32; x32 is about 15% faster on average than either. I call this "real x32" because the compiler produces actual x32 executables. One could imagine a rather different set of design choices: * produces x86-64 executables * no address space limitations * Int is 64 bits, as is Addr# * heap layout is just like on x86-64 (in particular, closures are 8-byte aligned) **except**: all pointers to other closures are stored as 4 bytes rather than 8 (possibly using "compressed references", e.g., address an 8 GB heap by storing a pointer to a closure at address `p` as `p >> 1`, with the two lowest bits used for pointer tagging) This would be less time-efficient than "real x32", but still give much of the space savings, while allowing a larger heap. Good for computations that need between 1 and 2 billion pointers' worth of storage, like compiling modestly complex Agda programs. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8287#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 19:31:26 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 19:31:26 -0000 Subject: [GHC] #8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault In-Reply-To: <046.a1de52e736c53bf94deece978e2702d5@haskell.org> References: <046.a1de52e736c53bf94deece978e2702d5@haskell.org> Message-ID: <061.7b4948ffe065be80738c2fb81ad3dcf5@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:53 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:53 -0000

#8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------+---------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by simonmar): * priority: normal => highest * milestone: => 7.8.1 Comment: I expect there's a decision being made about whether to link dynamically based on `DYNAMIC_GHC_PROGRAMS` rather than whether the program was compiled with `-dynamic` or not. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8376#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 20:01:11 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 20:01:11 -0000 Subject: [GHC] #8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault In-Reply-To: <046.a1de52e736c53bf94deece978e2702d5@haskell.org> References: <046.a1de52e736c53bf94deece978e2702d5@haskell.org> Message-ID: <061.4f8cf1250a092bbec9d4520c389dc29a@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:54 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:54 -0000

I expect there's a decision being made about whether to link dynamically

#8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------+---------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by darchon): Replying to [comment:2 simonmar]: based on `DYNAMIC_GHC_PROGRAMS` rather than whether the program was compiled with `-dynamic` or not. The `haddock` executables referred to in the bug report are built using a `cabal install`; they do not refer to a `haddock` executable build during a `make` in the `ghc` build-tree. I'm not building `haddock` during my build of `ghc` (ref. the `HADDOCK_DOCS=NO` in my `build.mk`). And I assume the `DYNAMIC_GHC_PROGRAMS` has no effect on the dynamic- linking decision made by `cabal`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8376#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 20:23:13 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 20:23:13 -0000 Subject: [GHC] #8256: adding locality levels to prefetch# and friends In-Reply-To: <045.bc455c21650626f3242606c828908318@haskell.org> References: <045.bc455c21650626f3242606c828908318@haskell.org> Message-ID: <060.b5d502ea59f22c3cbbd547a6228b9318@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:54 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:54 -0000

#8256: adding locality levels to prefetch# and friends -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: task | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8252 ,#8107 -------------------------------------+------------------------------------ Comment (by carter): Hey Simon, excellent questions 1) the motivation for the can_fail attribute is the following: anyone using prefetch (or at least using prefetch appropriately) are treating the CPU's memory bandwidth as a resource, and accordingly (and conservatively), can_fail prevents let floating/hoisting (if i've read the docs correctly), while still making it "cheap" to inline. It need not have the can_fail attribute, but since prefetches should/will only be used in pretty perf sensitive code, it seems like its a decent arbitrary choice that will help make "when" prefetch happens a bit easier to understand. 2) good points, i'll hack out a patch to docs later this week when i'm not buried with my consulting work -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8256#comment:36 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 20:29:44 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 20:29:44 -0000 Subject: [GHC] #8256: adding locality levels to prefetch# and friends In-Reply-To: <045.bc455c21650626f3242606c828908318@haskell.org> References: <045.bc455c21650626f3242606c828908318@haskell.org> Message-ID: <060.3cde9dc7d8179f5842da277ac07a2bde@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:54 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:54 -0000

#8256: adding locality levels to prefetch# and friends -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: task | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8252 ,#8107 -------------------------------------+------------------------------------ Comment (by carter): theres perhaps an argument for not having the can_fail = true attribute, but it seems like the "no float out" would help with reasoning about when prefetch happens -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8256#comment:37 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 21:08:16 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 21:08:16 -0000 Subject: [GHC] #8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault In-Reply-To: <046.a1de52e736c53bf94deece978e2702d5@haskell.org> References: <046.a1de52e736c53bf94deece978e2702d5@haskell.org> Message-ID: <061.c1d645ff8db8428198b514ed6378e853@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:54 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:54 -0000

#8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------+---------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by darchon): On Linux (GHC-b84fbabb0cad88a5b1ae62a53e04075383bc11f4), using a statically-linked `haddock`, I get: {{{ ~/devel/lens/src (master *)$ haddock -v3 Control/Lens/Internal/ByteString.hs Creating interfaces... Haddock coverage: Checking module Control.Lens.Internal.Level... Creating interface... 100% ( 6 / 6) in 'Control.Lens.Internal.Level' <MORE LOG MESSAGES> 100% ( 6 / 6) in 'Control.Lens.Internal.Getter' Checking module Control.Lens.Internal.Fold... <command line>: can't load .so/.DLL for: /home/baaijcpr/multi- ghc/7.7.20131002/lib/ghc-7.7.20131002/ghc-prim-0.3.1.0/libHSghc- prim-0.3.1.0-ghc7.7.20131002.so (/home/baaijcpr/multi- ghc/7.7.20131002/lib/ghc-7.7.20131002/ghc-prim-0.3.1.0/libHSghc- prim-0.3.1.0-ghc7.7.20131002.so: undefined symbol: stg_forkOnzh) }}} Also on Linux, the dynamically-linked `haddock` runs _without_ failure. I also want to note that `Control.Lens.Internal.Fold` is one of the source-files in the `lens` package that contains a `{-# ANN ... #-}` annotation. Removing the annotation makes the statically-linked haddock go through until another file with a `{-# ANN ... #-}` annotation is found, and subsequently stops with the same failure. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8376#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 2 21:42:40 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Oct 2013 21:42:40 -0000 Subject: [GHC] #8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault In-Reply-To: <046.a1de52e736c53bf94deece978e2702d5@haskell.org> References: <046.a1de52e736c53bf94deece978e2702d5@haskell.org> Message-ID: <061.50f10f044b8add7ee70f1fc1451d0651@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:54 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:54 -0000

#8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------+---------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by darchon): I want to point out that this bug will affect very _few_ users of GHC, at least initially. The reason: `haddock` will normally be build using dynamic-linking in the normal build/distribution process of GHC; and the dynamically-linked version shows no problems. Only if a user reinstalls `haddock`, e.g. doing a `cabal install haddock --reinstall`, will he encounter the described bug. That is because static- linking is (currently) the default for all executables built using `cabal`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8376#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 00:14:05 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 00:14:05 -0000 Subject: [GHC] #8400: Migrate the RTS to use libuv (or libev, or libevent) Message-ID: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:54 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:54 -0000

#8400: Migrate the RTS to use libuv (or libev, or libevent) ----------------------------------------------+---------------------------- Reporter: schyler | Owner: Type: feature request | simonmar Priority: normal | Status: new Component: Runtime System | Milestone: Keywords: | Version: Architecture: Unknown/Multiple | Operating System: Difficulty: Project (more than a week) | Unknown/Multiple Blocked By: | Type of failure: Related Tickets: 635, 7353 | None/Unknown | Test Case: | Blocking: ----------------------------------------------+---------------------------- This is mainly a reference discussion ticket. libuv (https://github.com/joyent/libuv) is a lightweight library which allows asynchronous IO across OpenBSD, Linux, Darwin, Windows etc by utilizing the fastest implementation on each system (epoll, kqueue, IOCP, event ports). These specialized IO polling methods are '''much''' faster on their respective platforms than just using select() like the RTS currently does. Additionally, it also provides cross platform threads, mutex, condition vars, terminal input/output and term settings w/ cross platform ANSI escape code handling, thread pools, cross platform HRC's etc. It's currently significantly faster than libevent and slightly faster than libev (and no doubt faster than rolling our own stuff). Because it's maintained and utilized heavily by Node.js it's in extremely active and maintained development. Rewriting a portion of the RTS to utilize libuv would have the following benefits; * We could ditch basically all of our platform specific code. Everything under rts/win32 and rts/posix, except the SEH stuff, could be deleted. * libuv is tuned for speed on each platform. This would be an optimization to all our async IO stuff. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8400 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 00:16:53 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 00:16:53 -0000 Subject: [GHC] #8400: Migrate the RTS to use libuv (or libev, or libevent) In-Reply-To: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> References: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> Message-ID: <061.6a92f097d41a1e11bc7ef9aaffa8c144@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:54 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:54 -0000

#8400: Migrate the RTS to use libuv (or libev, or libevent) ----------------------------+---------------------------------------------- Reporter: schyler | Owner: simonmar Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Project (more than a week) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: 635, 7353 Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by schyler): Correction: kqueue/epoll support currently does exist, but it seems to be in GHC.Event rather than baked into the RTS (?). #7353 discusses using IOCP on Windows. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8400#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 00:18:18 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 00:18:18 -0000 Subject: [GHC] #8400: Migrate the RTS to use libuv (or libev, or libevent) In-Reply-To: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> References: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> Message-ID: <061.39494a4174f85c10ab04d22cb617ae01@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:55 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:55 -0000

#8400: Migrate the RTS to use libuv (or libev, or libevent) ----------------------------+---------------------------------------------- Reporter: schyler | Owner: simonmar Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Project (more than a week) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: 635, 7353 Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Changes (by schyler): * cc: schyler (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8400#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 00:35:11 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 00:35:11 -0000 Subject: [GHC] #8400: Migrate the RTS to use libuv (or libev, or libevent) In-Reply-To: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> References: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> Message-ID: <061.8838ef0f7910eaaec6a4c1fdb960d609@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:55 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:55 -0000

#8400: Migrate the RTS to use libuv (or libev, or libevent) ----------------------------+---------------------------------------------- Reporter: schyler | Owner: simonmar Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Project (more than a week) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: 635, 7353 Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by tibbe): You might want to start by reading the 3 papers of the I/O manager's evolution and implementation: Extending the Haskell Foreign Function Interface with Concurrency http://community.haskell.org/~simonmar/papers/conc-ffi.pdf Scalable I/O Event Handling for GHC http://research.google.com/pubs/archive/36841.pdf Mio: A High-Performance Multicore IO Manager for GHC http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask035-voellmy.pdf We briefly considered using libev when we did the first I/O manager rewrite, but any library that relies on callbacks will not work well as callbacks from C to Haskell are expensive. I have thought about integrating the I/O manager, which now runs in a separate thread, into the scheduler this might (or might not) give us lower latency and somewhat better request/s performance per core. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8400#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 01:38:30 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 01:38:30 -0000 Subject: [GHC] #8401: parsec issues Message-ID: <047.cbaa79be6f9836aeaa184dc57763560c@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:55 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:55 -0000

#8401: parsec issues ----------------------------------+--------------------------------------- Reporter: dsamperi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- Built ghc-7.7 using BuildFlavour quick under Fedora 18 Linux and I encounter a problem after installing parsec and trying to load example ch16/csv9.hs from RealWorldHaskell: Could not find module 'Text.ParserCombinators.Parsec' Perhaps you haven't installed the "dyn" libraries for package parsec-3.1.3 There are also Warnings while installing parsec: Data/Text/Lazy/Builder/Int.hs:52:11: Warning: Rule "decimal/Int" may never fire because ?decimal? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ?decimal? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8401 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 02:04:00 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 02:04:00 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.4afec0b36fe77d6f4b02e2ea886c1239@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:55 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:55 -0000

From ghc-devs at haskell.org Thu Oct 3 02:05:53 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 02:05:53 -0000 Subject: [GHC] #8134: ghc enters a loop while building 7.6.3 for

#8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by kazu-yamamoto): I hope this patch will be merged quickly. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8266#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler powerpc64 platform. In-Reply-To: <043.0289be94f89f3f22e5a1a6cc61dcce1b@haskell.org> References: <043.0289be94f89f3f22e5a1a6cc61dcce1b@haskell.org> Message-ID: <058.c5d04e46a7357d17d6c0605bd376d243@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:55 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:55 -0000 #8134: ghc enters a loop while building 7.6.3 for powerpc64 platform. -------------------------------------+----------------------------- Reporter: k0da | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.3 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+----------------------------- Comment (by juhpetersen): The problem also happens on s390x. You can find some more details in the Fedora bug tracking this: https://bugzilla.redhat.com/show_bug.cgi?id=989593 Basically it looks like some kind of process lockup or race condition which seems to happen randomly during the above big "ghc -M -dep-makefile" invocation above. A subprocess has completed but somehow ghc is still hanging on it. {{{ 15692 pts/3 Ssl+ 3:37 /usr/lib64/ghc-7.6.3/ghc -B/usr/lib64/ghc-7.6.3 -optc-I/usr/include -v1 -M -dep-m 16531 pts/3 Z+ 0:00 \_ [gcc] <defunct> }}} There seems to be no systematic pattern - I didn't count the number of source files being preprocessed but it seems to happen each time quite some way into the processing of the files for me. gdb shows ghc is hung on {{{ #0 0x00000080c6c31ad0 in .pthread_cond_wait () from /lib64/libpthread.so.0 }}} Still not completely sure if this is a ghc or glibc issue or some conflict between them. Apparently the pthread handling on non-intel glibc is different from intel platforms. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8134#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 02:12:52 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 02:12:52 -0000 Subject: [GHC] #8276: Building Haddock documentation panics with perf build on x86_64 Linux In-Reply-To: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> References: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> Message-ID: <063.754bc65b5d449b967dbe40a3865d8ced@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:55 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:55 -0000

#8276: Building Haddock documentation panics with perf build on x86_64 Linux ---------------------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Documentation | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by kazu-yamamoto): Compiling test.hs with dynamic linking results in False. Strange. {{{ % ghc -O2 -package ghc test.hs -fforce-recomp % ./test False % ghc -O2 -dynamic -package ghc test.hs -fforce-recomp % ./test False }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8276#comment:27 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 02:20:44 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 02:20:44 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.0dc9583e301ee183ef5c8b39d8fc2381@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:55 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:55 -0000

#8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by kazu-yamamoto): Wait. A program compiled with dynamic linking cannot search its libraries: {{{ % cat test.hs main = putStrLn "Hello" % ghc -fforce-recomp -dynamic test.hs % ./test dyld: Library not loaded: @rpath/base-4.7.0.0/libHSbase-4.7.0.0-ghc7.7.20131001.dylib Referenced from: /Users/kazu/./test Reason: image not found zsh: trace trap ./test }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8266#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 02:35:43 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 02:35:43 -0000 Subject: [GHC] #8396: cleanup / refactor native code gens In-Reply-To: <045.aa7cf1c57555c9884c0054e57028458c@haskell.org> References: <045.aa7cf1c57555c9884c0054e57028458c@haskell.org> Message-ID: <060.3bf28caa8440d8235e16e9ffa528082e@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:55 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:55 -0000

#8396: cleanup / refactor native code gens ----------------------------------+---------------------------------------- Reporter: carter | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: None/Unknown | Related Tickets: #8299 , #8287 ,#8272 Test Case: | Blocking: | ----------------------------------+---------------------------------------- Comment (by schyler): Probably not useful or related, but reminded me of some work I found on github (https://github.com/mlite/HsLlvm) which started implementing some of the llvm passes (like mem2reg) using hoopl. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8396#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 03:25:47 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 03:25:47 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.21fe8fa252d03a921e818e575c3fb52f@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:56 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:56 -0000

#8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by kazu-yamamoto): GHC should call GCC with "-Wl,-rpath,<path>": {{{ % cat test.hs main = putStrLn "Hello" % ghc -fforce-recomp -dynamic test.hs -optl "-Wl,-rpath,/ghc- head/lib/ghc-7.7.20131001/" % ./test Hello }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8266#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 03:35:04 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 03:35:04 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.5968eb464bb0f2f250525e66c9245f7a@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:56 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:56 -0000

#8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by kazu-yamamoto): "8226_fix.patch" should be merged. And GHC on Mac should also specify "-Wl,-rpath,<path>" to GCC when the -dynamic option is specified. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8266#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 03:44:06 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 03:44:06 -0000 Subject: [GHC] #8139: ghc 7.6.3 and ghc HEAD fails to build on OS X 10.9 In-Reply-To: <052.92009bd3b6836bd26916c16cd983224b@haskell.org> References: <052.92009bd3b6836bd26916c16cd983224b@haskell.org> Message-ID: <067.4c344ff02b520209b95133d90cde055a@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:56 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:56 -0000

#8139: ghc 7.6.3 and ghc HEAD fails to build on OS X 10.9 -------------------------------------+------------------------------------- Reporter: darinmorrison | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by darinmorrison): Replying to [comment:10 george.colpitts]: Actually, no. This patch fixes problems that occur when building on 10.9 regardless of whether GCC or clang (Xcode 5) are used. In other words, it's not related to Xcode 5 at all. Building GHC on 10.8 with Xcode 5 does not require this patch. I've already tested this to make sure. You can see how the patch is applied with the homebrew formula I maintain here: https://github.com/darinmorrison/homebrew- haskell/blob/master/Formula/ghc.rb -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8139#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 03:58:30 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 03:58:30 -0000 Subject: [GHC] #8139: ghc 7.6.3 and ghc HEAD fails to build on OS X 10.9 In-Reply-To: <052.92009bd3b6836bd26916c16cd983224b@haskell.org> References: <052.92009bd3b6836bd26916c16cd983224b@haskell.org> Message-ID: <067.eb92eaba89b3f242dbda02b46414c3cb@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:56 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:56 -0000

#8139: ghc 7.6.3 and ghc HEAD fails to build on OS X 10.9 -------------------------------------+------------------------------------- Reporter: darinmorrison | Owner: darinmorrison Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by darinmorrison): * owner: => darinmorrison Comment: Quick update on this: I've put together a proper patch for this against HEAD that I intend to submit by this weekend, closing the issue. By all indications, the patch above has been working fine and hasn't caused any failures. I want to do a little bit more testing first but otherwise I think this one is basically sorted. I'll include this patch in a 7.6.3 hotfix release for 10.9 users that also includes backported clang-fixes from thoughtpolice. The backporting is basically done but needs a bit more testing. Should be ready by next week if not sooner. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8139#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 05:46:32 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 05:46:32 -0000 Subject: [GHC] #8396: cleanup / refactor native code gens In-Reply-To: <045.aa7cf1c57555c9884c0054e57028458c@haskell.org> References: <045.aa7cf1c57555c9884c0054e57028458c@haskell.org> Message-ID: <060.db8c1d0267220fee80906e33e2708ba9@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:56 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:56 -0000

#8396: cleanup / refactor native code gens ----------------------------------+---------------------------------------- Reporter: carter | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: None/Unknown | Related Tickets: #8299 , #8287 ,#8272 Test Case: | Blocking: | ----------------------------------+---------------------------------------- Comment (by carter): schyler, you raise a good point. Currently HOOPL isn't used at all! This is because a *single* hoopl pass will apparently increase the compilation time of programs by 5%, so adding a number of hoopl passes would seriously blow up the compilation time. i'm not really touching on improving the optimization story, that'd be a subsequent effort and much more work. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8396#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 07:35:10 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 07:35:10 -0000 Subject: [GHC] #8388: forall on non-* types In-Reply-To: <047.f92d46972e6180e14068208ce6b24ecd@haskell.org> References: <047.f92d46972e6180e14068208ce6b24ecd@haskell.org> Message-ID: <062.edf21d12609354010fe84ab4a62e7cff@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:56 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:56 -0000

#8388: forall on non-* types -------------------------------------+------------------------------------ Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): You are quite right about this, but GHC currently doesn't check that the body of a `forall` has kind `*`. Indeed `TcHsType` has this comment {{{ Really we should check that it's a type of value kind {*, Constraint, #}, but I'm not doing that yet Example that should be rejected: f :: (forall (a:*->*). a) Int }}} This is for several reasons, all minor: * The body can also have kind `#`, eg `forall a. (# a, a #)` * If we have explicit `foralls` in kinds (which we don't yet), the body will have kind `BOX` not `*`. * In this generalised-newtype-deriving code (cf #3621) {{{ class C s m where newtype WrappedState a = WS ... deriving (C s) }}} the `(C s)` part is hackily represented as `forall state. C s`. This is a convenient hack that would have to be done some other way. * The error message for `T7019` and `T7019a` changed, not in a good way. None of these are fatal, but I don't think this bug is causing a problem today, so I'm going to leave this for now. Below is the diff to `TcHsTypes` which I tried, as a starting point. Simon {{{ diff --git a/compiler/typecheck/TcHsType.lhs b/compiler/typecheck/TcHsType.lhs index b7cd841..20a5f99 100644 --- a/compiler/typecheck/TcHsType.lhs +++ b/compiler/typecheck/TcHsType.lhs @@ -393,13 +393,16 @@ tc_hs_type hs_ty@(HsAppTy ty1 ty2) exp_kind (fun_ty, arg_tys) = splitHsAppTys ty1 [ty2] --------- Foralls -tc_hs_type hs_ty@(HsForAllTy _ hs_tvs context ty) exp_kind - = tcHsTyVarBndrs hs_tvs $ \ tvs' -> +tc_hs_type hs_ty@(HsForAllTy _ hs_tvs context ty) exp_kind@(EK exp_k _) + = tcHsTyVarBndrs hs_tvs $ \ tvs' -> -- Do not kind-generalise here! See Note [Kind generalisation] do { ctxt' <- tcHsContext context ; ty' <- if null (unLoc context) then -- Plain forall, no context - tc_lhs_type ty exp_kind -- Why exp_kind? See Note [Body kind of forall] - else + do { checkExpectedKind hs_ty exp_k ekOpen + -- Check that the expected kind is *, #, or Constraint + -- See Note [Body kind of forall] + ; tc_lhs_type ty exp_kind } + else -- If there is a context, then this forall is really a -- _function_, so the kind of the result really is * -- The body kind (result of the function can be * or #, hence ekOpen @@ -408,7 +411,7 @@ tc_hs_type hs_ty@(HsForAllTy _ hs_tvs context ty) exp_kind ; return (mkSigmaTy tvs' ctxt' ty') } --------- Lists, arrays, and tuples -tc_hs_type hs_ty@(HsListTy elt_ty) exp_kind +tc_hs_type hs_ty@(HsListTy elt_ty) exp_kind = do { tau_ty <- tc_lhs_type elt_ty ekLifted ; checkExpectedKind hs_ty liftedTypeKind exp_kind ; checkWiredInTyCon listTyCon @@ -779,11 +782,11 @@ Note [Body kind of a forall] The body of a forall is usually a type, but in principle there's no reason to prohibit *unlifted* types. In fact, GHC can itself construct a function with an -unboxed tuple inside a for-all (via CPR analyis; see +unboxed tuple inside a for-all (via CPR analyis; see typecheck/should_compile/tc170). Moreover in instance heads we get forall-types with -kind Constraint. +kind Constraint. Moreover if we have a signature f :: Int# @@ -816,9 +819,9 @@ So we *must* keep the HsForAll on the instance type HsForAll Implicit [] [] (Typeable Apply) so that we do kind generalisation on it. -Really we should check that it's a type of value kind -{*, Constraint, #}, but I'm not doing that yet -Example that should be rejected: +We do check that it's a type of value kind {*, Constraint, #}, via the +call (checkExpectedKind hs_ty exp_k ekOpen) in the null-context case. +(c.f. Trac #8388). Example that should be rejected: f :: (forall (a:*->*). a) Int Note [Inferring tuple kinds] }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8388#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 07:46:47 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 07:46:47 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.416755933a28c2be2aff51ab4e783fc1@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:56 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:56 -0000

#8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by simonpj): * status: new => patch * milestone: => 7.8.1 Comment: I am not following the details of this patch (I'm afraid I'm clueless about dynamic linking), but I'll milestone this for 7.8.1 and change it to `patch`, so that Austin is sure to see it. Austin: I'm not expressing an opinion about whether this is "ready", just wanting to be sure you review it. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8266#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 08:25:38 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 08:25:38 -0000 Subject: [GHC] #8392: Suggest AllowAmbiguousTypes In-Reply-To: <047.260dbec4450efd89f823d0de3b069a9d@haskell.org> References: <047.260dbec4450efd89f823d0de3b069a9d@haskell.org> Message-ID: <062.8d67b0113af88934546c26545a1ed5be@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:56 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:56 -0000

#8392: Suggest AllowAmbiguousTypes --------------------------------------------+------------------------------ Reporter: rwbarton | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Simon Peyton Jones ): In [changeset:41f708b6e0f4c73eb652045a1b9b4254eec97234/testsuite]: {{{ #!CommitTicketReference repository="testsuite" revision="41f708b6e0f4c73eb652045a1b9b4254eec97234" Test Trac #8392 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8392#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 08:25:52 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 08:25:52 -0000 Subject: [GHC] #8334: unexpected type inference failure in main In-Reply-To: <045.d6a36c2816853d30302d2d9c38d5abe8@haskell.org> References: <045.d6a36c2816853d30302d2d9c38d5abe8@haskell.org> Message-ID: <060.b3e33864856be5ae31942e2bb56d41d6@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:56 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:56 -0000

#8334: unexpected type inference failure in main -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:9864edf2557d7a52a4c3d8cccfe1e9e12bf26ebf/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9864edf2557d7a52a4c3d8cccfe1e9e12bf26ebf" Look through tick-boxes when looking for integral literals in the desugarer Fixes Trac #8334 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8334#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 08:25:52 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 08:25:52 -0000 Subject: [GHC] #3725: Annotations not written to interface files In-Reply-To: <041.dfa4280aa188470f7b07eff4da2beab3@haskell.org> References: <041.dfa4280aa188470f7b07eff4da2beab3@haskell.org> Message-ID: <056.b78f60e8b084be29799d928df671a08a@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:57 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:57 -0000

#3725: Annotations not written to interface files -------------------------------+------------------------------------------- Reporter: rl | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: 7867 | -------------------------------+------------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:7996d8f45866ac8bdf1da189ca6ef1bc38bfe3eb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7996d8f45866ac8bdf1da189ca6ef1bc38bfe3eb" Tidy up the commit for Trac #3725 In particular, the mi_ann_fn field in ModIface was only being used totally locally in MkIface, so I made it local. Other than that I just refactored data types slightly, * Adding synonym Annotations.AnnPayload for the cryptic Serialized * Adding MkIface.IfaceIdExtras to common up some of the identical code }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/3725#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 08:25:53 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 08:25:53 -0000 Subject: [GHC] #8392: Suggest AllowAmbiguousTypes In-Reply-To: <047.260dbec4450efd89f823d0de3b069a9d@haskell.org> References: <047.260dbec4450efd89f823d0de3b069a9d@haskell.org> Message-ID: <062.08c6e23e84c7adcac0627afbe495c813@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:57 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:57 -0000

#8392: Suggest AllowAmbiguousTypes --------------------------------------------+------------------------------ Reporter: rwbarton | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Simon Peyton Jones ): In [changeset:43856a003c9abb1bf8bf1822e6e7f5781b16ac4d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="43856a003c9abb1bf8bf1822e6e7f5781b16ac4d" Improve -XAllowAmbiguousTypes (Trac #8392) * Add a suggestion to add AllowAmbiguousTypes when there is an ambiguity error * Move some of the logic to tcSimplifyAmbiguityCheck * Report inaccessible code regardless of the ambiguity check }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8392#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 08:25:54 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 08:25:54 -0000 Subject: [GHC] #8391: FunDeps coverage condition check failure with PolyKinds In-Reply-To: <047.b2bf3b0730ed8141c814d71a4a379642@haskell.org> References: <047.b2bf3b0730ed8141c814d71a4a379642@haskell.org> Message-ID: <062.fddd793029b9ba2c618948f449e10323@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:57 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:57 -0000

#8391: FunDeps coverage condition check failure with PolyKinds ----------------------------------------------+---------------------------- Reporter: sbarclay | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8356 ----------------------------------------------+---------------------------- Comment (by Simon Peyton Jones ): In [changeset:9d908c523bf61936ef372b70d5f8548fb36da26e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9d908c523bf61936ef372b70d5f8548fb36da26e" Close over kinds when checking fundep coverage (Trac #8391) See Note [Closing over kinds in coverage] in FunDeps }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8391#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 08:29:23 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 08:29:23 -0000 Subject: [GHC] #8392: Suggest AllowAmbiguousTypes In-Reply-To: <047.260dbec4450efd89f823d0de3b069a9d@haskell.org> References: <047.260dbec4450efd89f823d0de3b069a9d@haskell.org> Message-ID: <062.fe7d755217aac45ae6ae8718bcc404cd@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:57 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:57 -0000

#8392: Suggest AllowAmbiguousTypes -------------------------------------------------+------------------------- Reporter: rwbarton | Owner: Type: feature request | simonpj Priority: normal | Status: Component: Compiler (Type checker) | closed Resolution: fixed | Milestone: Operating System: Unknown/Multiple | Version: 7.7 Type of failure: None/Unknown | Keywords: Test Case: | Architecture: typecheck/should_fail/T8392a, | Unknown/Multiple typecheck/should_compile/T8392 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * status: new => closed * testcase: => typecheck/should_fail/T8392a, typecheck/should_compile/T8392 * resolution: => fixed -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8392#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 08:32:04 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 08:32:04 -0000 Subject: [GHC] #8334: unexpected type inference failure in main In-Reply-To: <045.d6a36c2816853d30302d2d9c38d5abe8@haskell.org> References: <045.d6a36c2816853d30302d2d9c38d5abe8@haskell.org> Message-ID: <060.40cd27a46252b68d8ad535d1c29afc69@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:57 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:57 -0000

#8334: unexpected type inference failure in main -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Darn that should be #8384 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8334#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 08:38:26 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 08:38:26 -0000 Subject: [GHC] #8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault In-Reply-To: <046.a1de52e736c53bf94deece978e2702d5@haskell.org> References: <046.a1de52e736c53bf94deece978e2702d5@haskell.org> Message-ID: <061.d3a833d73f9f1bbfb1f9ce9fb7353ba3@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:57 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:57 -0000

#8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------+---------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by simonmar): The problem is not in Haddock, it's the GHC API. GHC's linker is using dynamic linking even when the program using the GHC API is linked statically, because it is using the value of `DYNAMIC_GHC_PROGRAMS`, which is set when GHC is built. We might not be able to support using the GHC API from a statically linked binary on all platforms, because it depends on having a working RTS linker, and that's what we wanted to move away from. But I think we can support it at least on ELF platforms where the RTS linker works for most things. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8376#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 09:03:55 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 09:03:55 -0000 Subject: [GHC] #8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault In-Reply-To: <046.a1de52e736c53bf94deece978e2702d5@haskell.org> References: <046.a1de52e736c53bf94deece978e2702d5@haskell.org> Message-ID: <061.ce8af634780f51e8e629a6b076620226@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:57 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:57 -0000

#8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------+---------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by darchon): Replying to [comment:6 simonmar]:

The problem is not in Haddock, it's the GHC API. GHC's linker is using dynamic linking even when the program using the GHC API is linked statically, because it is using the value of `DYNAMIC_GHC_PROGRAMS`, which is set when GHC is built. Indeed, I initially noticed the bug in my own program that uses the GHC API. I just reference `haddock` in the bug report as it is such a widely used tool.

If the problem is not fixed before the release of 7.8.1, perhaps it could at least be mentioned in the release notes that it is advised that executables (transitively) using the GHC API should be linked dynamically? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8376#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 09:18:10 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 09:18:10 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.7ef306ad78b190b847429d07aed50f45@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:57 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:57 -0000

Wait. A program compiled with dynamic linking cannot search its

#8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by darchon): Replying to [comment:7 kazu-yamamoto]: libraries:

{{{ % cat test.hs main = putStrLn "Hello" % ghc -fforce-recomp -dynamic test.hs % ./test dyld: Library not loaded:

@rpath/base-4.7.0.0/libHSbase-4.7.0.0-ghc7.7.20131001.dylib

Referenced from: /Users/kazu/./test Reason: image not found zsh: trace trap ./test }}} Indeed, my patch does not resolve that problem, as I considered it as something separate from the reported bug. My patch only touches the built/make system, and only removes references to the built tree in the created libraries. I want to note that the problem you describe in your comment also occurs in the current, unpatched, version of ghc.

-- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8266#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 09:53:08 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 09:53:08 -0000 Subject: [GHC] #8402: throwTo segfaults under -prof -threaded -with-rtsopts=N2 Message-ID: <043.0ab089710edd4b363b63a9d75aa20e5f@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:57 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:57 -0000

#8402: throwTo segfaults under -prof -threaded -with-rtsopts=N2 ----------------------------------+---------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- Save the following module as {{{throwto.hs}}} {{{ import Control.Concurrent import Control.Exception import Control.Monad main = do tid <- mask_ $ forkIO $ void $ (try $ threadDelay 100000 :: IO (Either SomeException ())) killThread tid }}} Then compile it with HEAD and run it: {{{ ghc-stage2 throwto.hs -prof -threaded -fforce-recomp ./throwto +RTS -N2 # segfaults }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8402 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 10:20:50 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 10:20:50 -0000 Subject: [GHC] #8402: throwTo segfaults under -prof -threaded -with-rtsopts=N2 In-Reply-To: <043.0ab089710edd4b363b63a9d75aa20e5f@haskell.org> References: <043.0ab089710edd4b363b63a9d75aa20e5f@haskell.org> Message-ID: <058.e883972c7a5042833650e6ca1a2138d8@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:57 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:57 -0000

#8402: throwTo segfaults under -prof -threaded -with-rtsopts=N2 ----------------------------------+---------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by akio): I see many different stack traces from this program, here is one of them: {{{ Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff56fe700 (LWP 14605)] 0x00000000008382d4 in overwritingClosure (p=0x7ffff6007a38) at includes/rts/storage/ClosureMacros.h:500 500 ((StgThunk *)(p))->payload[i] = 0; (gdb) bt #0 0x00000000008382d4 in overwritingClosure (p=0x7ffff6007a38) at includes/rts/storage/ClosureMacros.h:500 #1 0x0000000000830eb4 in doneWithMsgThrowTo (m=0x7ffff6007a38) at rts/Messages.h:25 #2 0x0000000000831a52 in maybePerformBlockedException (cap=0xbbc0c0, tso=0x7ffff60079b0) at rts/RaiseAsync.c:539 #3 0x000000000083aa9f in threadPaused (cap=0xbbc0c0, tso=0x7ffff60079b0) at rts/ThreadPaused.c:209 #4 0x0000000000852dc5 in stg_returnToSchedButFirst () #5 0x0000000000000000 in ?? () }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8402#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 10:26:48 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 10:26:48 -0000 Subject: [GHC] #8402: throwTo segfaults under -prof -threaded -with-rtsopts=N2 In-Reply-To: <043.0ab089710edd4b363b63a9d75aa20e5f@haskell.org> References: <043.0ab089710edd4b363b63a9d75aa20e5f@haskell.org> Message-ID: <058.828ddac97c5e580cddb4d94e1e7aa0e9@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:58 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:58 -0000

#8402: throwTo segfaults under -prof -threaded -with-rtsopts=N2 ----------------------------------+---------------------------------- Reporter: akio | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by akio): * status: new => patch Comment: The attached patch seems to fix this. I haven't figured out how I should validate it, since a normal validate run doesn't run many tests with profiling, so I just did {{{make}}} in {{{testsuite/tests/profiling/should_run}}}. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8402#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 10:27:10 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 10:27:10 -0000 Subject: [GHC] #8402: throwTo segfaults under -prof -threaded -with-rtsopts=N2 In-Reply-To: <043.0ab089710edd4b363b63a9d75aa20e5f@haskell.org> References: <043.0ab089710edd4b363b63a9d75aa20e5f@haskell.org> Message-ID: <058.bcaeb9b20e24fe623feed49bc28d6f99@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:58 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:58 -0000

#8402: throwTo segfaults under -prof -threaded -with-rtsopts=N2 ----------------------------------+---------------------------------- Reporter: akio | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Profiling | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by akio): * component: Compiler => Profiling -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8402#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 10:29:10 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 10:29:10 -0000 Subject: [GHC] #7747: debug_p RTS is buggy (debugging and profiled) In-Reply-To: <045.1bf66d64303a83a25fe6997908d81ac8@haskell.org> References: <045.1bf66d64303a83a25fe6997908d81ac8@haskell.org> Message-ID: <060.6c7222ee88ebd2b5c4350c06fffc8710@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:58 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:58 -0000

#7747: debug_p RTS is buggy (debugging and profiled) -------------------------------------+------------------------------------ Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: Component: Profiling | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by akio): * difficulty: => Unknown Comment: I think the fix is causing #8402. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7747#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 11:10:52 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 11:10:52 -0000 Subject: [GHC] #8391: FunDeps coverage condition check failure with PolyKinds In-Reply-To: <047.b2bf3b0730ed8141c814d71a4a379642@haskell.org> References: <047.b2bf3b0730ed8141c814d71a4a379642@haskell.org> Message-ID: <062.3177822dcf0bb333559078172196b851@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:58 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:58 -0000

#8391: FunDeps coverage condition check failure with PolyKinds ----------------------------------------------+---------------------------- Reporter: sbarclay | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8356 ----------------------------------------------+---------------------------- Comment (by Simon Peyton Jones ): In [changeset:d16da2f376d5994add04ba8e5b2fac4bc91f8e68/testsuite]: {{{ #!CommitTicketReference repository="testsuite" revision="d16da2f376d5994add04ba8e5b2fac4bc91f8e68" Test Trac #8391 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8391#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 11:12:50 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 11:12:50 -0000 Subject: [GHC] #8391: FunDeps coverage condition check failure with PolyKinds In-Reply-To: <047.b2bf3b0730ed8141c814d71a4a379642@haskell.org> References: <047.b2bf3b0730ed8141c814d71a4a379642@haskell.org> Message-ID: <062.4c31fee4c78a8e3a2a7cfb1aab8b07a1@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:58 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:58 -0000

#8391: FunDeps coverage condition check failure with PolyKinds ----------------------------------------------+---------------------------- Reporter: sbarclay | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: polykinds/T8391 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8356 ----------------------------------------------+---------------------------- Changes (by simonpj): * status: new => closed * testcase: => polykinds/T8391 * resolution: => fixed Comment: Fixed thank you. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8391#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 11:14:45 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 11:14:45 -0000 Subject: [GHC] #8384: -fwarn-empty-enumerations doesn't work with -fhpc In-Reply-To: <047.361031c50d7fb6d449576268f372ad82@haskell.org> References: <047.361031c50d7fb6d449576268f372ad82@haskell.org> Message-ID: <062.416b83755124ae3a1095989606a67b05@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:58 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:58 -0000

#8384: -fwarn-empty-enumerations doesn't work with -fhpc -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): In [changeset:9864edf2557d7a52a4c3d8cccfe1e9e12bf26ebf/ghc]: {{{ Look through tick-boxes when looking for integral literals in the desugarer Fixes Trac #8334 }}} (I mis-typed the commit message, but it is for ''this'' ticket #8384) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8384#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 11:16:23 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 11:16:23 -0000 Subject: [GHC] #8384: -fwarn-empty-enumerations doesn't work with -fhpc In-Reply-To: <047.361031c50d7fb6d449576268f372ad82@haskell.org> References: <047.361031c50d7fb6d449576268f372ad82@haskell.org> Message-ID: <062.e47490c512359c0d5cb205da749bddbe@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:58 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:58 -0000

#8384: -fwarn-empty-enumerations doesn't work with -fhpc -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:c340764cfe3ba84fb2722e7c6638121108c46aee/testsuite]: {{{ #!CommitTicketReference repository="testsuite" revision="c340764cfe3ba84fb2722e7c6638121108c46aee" Trac #T7881 now works for hpc way again As a result of fixing Trac #8384 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8384#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 11:17:05 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 11:17:05 -0000 Subject: [GHC] #8384: -fwarn-empty-enumerations doesn't work with -fhpc In-Reply-To: <047.361031c50d7fb6d449576268f372ad82@haskell.org> References: <047.361031c50d7fb6d449576268f372ad82@haskell.org> Message-ID: <062.eb4e5fa06a8165e12460ad2bb9c511e1@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:58 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:58 -0000

#8384: -fwarn-empty-enumerations doesn't work with -fhpc -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: numeric/T7881 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * status: new => closed * testcase: => numeric/T7881 * resolution: => fixed Comment: Thanks; easy fix. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8384#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 11:31:40 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 11:31:40 -0000 Subject: [GHC] #8256: adding locality levels to prefetch# and friends In-Reply-To: <045.bc455c21650626f3242606c828908318@haskell.org> References: <045.bc455c21650626f3242606c828908318@haskell.org> Message-ID: <060.57d72950b11b6733a76764161d870b84@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:58 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:58 -0000

#8256: adding locality levels to prefetch# and friends -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: task | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8252 ,#8107 -------------------------------------+------------------------------------ Comment (by simonpj): Thank you for (1). But when you fix (2) can you add those remarks to `primops.txt.pp` (as a comment, perhaps), rather than just telling me! Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8256#comment:38 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 12:00:45 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 12:00:45 -0000 Subject: [GHC] #8357: Pretty printing of kind-involving inferred types In-Reply-To: <042.64c49f0a6524a9882ff40c2a141a092f@haskell.org> References: <042.64c49f0a6524a9882ff40c2a141a092f@haskell.org> Message-ID: <057.4c5f8eba2fe0bbe5a2958db7297ad7db@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:59 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:59 -0000

#8357: Pretty printing of kind-involving inferred types -------------------------------------+------------------------------------ Reporter: ksf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): This commit improves matters a lot {{{ commit 66c5ddba449e78a174e989ea35783eb6c793e483 Author: unknown <simonpj at MSRC-4971295.europe.corp.microsoft.com> Date: Tue Oct 1 16:34:00 2013 +0100 Improve pretty-printing of types * The main change is to suppress printing (in types) of kind for-alls kind applications The new flag -fprint-explicit-kinds prints them as before (by analogy with the existing -fprint-explicit-foralls) * I also took advantage of the fact that SDoc now has access to DynFlags, to tidy up the way in which explicit for-alls are printed. Instead of passing a boolean flag around, we now simply consult the DynFlags. Much neater. I still need to add documentation for the flag }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8357#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 13:52:55 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 13:52:55 -0000 Subject: [GHC] #8402: throwTo segfaults under -prof -threaded -with-rtsopts=N2 In-Reply-To: <043.0ab089710edd4b363b63a9d75aa20e5f@haskell.org> References: <043.0ab089710edd4b363b63a9d75aa20e5f@haskell.org> Message-ID: <058.e11ea6832b2e26bcd8db386f5ff4a29d@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:59 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:59 -0000

#8402: throwTo segfaults under -prof -threaded -with-rtsopts=N2 ----------------------------------+---------------------------------- Reporter: akio | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Profiling | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by simonmar): * cc: ezyang (added) * priority: normal => highest * milestone: => 7.8.1 Comment: Just to be clear for those watching this ticket: this just affects profiling with `+RTS -N`. Here are the rules, documented next to `overwritingClosure`: * We cannot zero slop when THREADED_RTS && +RTS -N * LDV profiling requires slop-zeroing, so we cannot do LDV profiling with +RTS -N If THREADED_RTS is on, then we only get into `overwritingClosure` if `PROFILING` is on. Originally we returned immediately if (PROFILING && !LDV), but Edward removed this, basically making it so that slop is always overwritten when PROFILING is on, which breaks the first rule above. I'd like to understand more about what Edward was fixing with his patch. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8402#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 14:11:33 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 14:11:33 -0000 Subject: [GHC] #8403: Pretty-printing of long types Message-ID: <047.792ac96369079bc46b579fe906221406@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:59 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:59 -0000

#8403: Pretty-printing of long types ------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Low priority, but this ghci output could be more packed. {{{ ?> :t (,,,,,,,,,,,,,,,,,,,,,,,) (,,,,,,,,,,,,,,,,,,,,,,,) :: a -> b -> c -> d -> e -> f -> g -> h -> i -> j -> k -> l -> m -> n -> o -> p -> q -> r -> s -> t -> u -> v -> w -> x -> (a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s, t, u, v, w, x) }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8403 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 14:23:03 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 14:23:03 -0000 Subject: [GHC] #8380: Numerous testsuite failures on ARM due to missing mkJumpToAddr In-Reply-To: <046.6822dd2c7a2b1392cbd1b6deb902b274@haskell.org> References: <046.6822dd2c7a2b1392cbd1b6deb902b274@haskell.org> Message-ID: <061.30b62827ac81db2ef3b6d91af31e6c49@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:59 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:59 -0000

#8380: Numerous testsuite failures on ARM due to missing mkJumpToAddr -------------------------------------+--------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: patch Operating System: Unknown/Multiple | Architecture: arm Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+--------------------------- Comment (by bgamari): What is the plan for merging this? I know the feature window for 7.8 has officially closed by I think this could be considered a bug-fix. Regardless, it should be a pretty harmless patch as it only touches the ARM path, implementing what was previous unimplemented. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8380#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 14:31:53 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 14:31:53 -0000 Subject: [GHC] #8380: Numerous testsuite failures on ARM due to missing mkJumpToAddr In-Reply-To: <046.6822dd2c7a2b1392cbd1b6deb902b274@haskell.org> References: <046.6822dd2c7a2b1392cbd1b6deb902b274@haskell.org> Message-ID: <061.9f8b11119fcf8a168da707629b7d0a6a@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:59 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:59 -0000

#8380: Numerous testsuite failures on ARM due to missing mkJumpToAddr -------------------------------------+--------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: patch Operating System: Unknown/Multiple | Architecture: arm Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+--------------------------- Changes (by simonpj): * status: new => patch * milestone: => 7.8.1 Comment: I don't know but I'll make it 'patch' status and milestone for 7.8, so that Austin should get to it before we release. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8380#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 14:40:25 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 14:40:25 -0000 Subject: [GHC] #8357: Pretty printing of kind-involving inferred types In-Reply-To: <042.64c49f0a6524a9882ff40c2a141a092f@haskell.org> References: <042.64c49f0a6524a9882ff40c2a141a092f@haskell.org> Message-ID: <057.81b9fe2050b5dca2d8156f9b9e697286@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:59 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:59 -0000

#8357: Pretty printing of kind-involving inferred types -------------------------------------+------------------------------------ Reporter: ksf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:06afa916d4f76e58903bdf133567d28499780f68/testsuite]: {{{ #!CommitTicketReference repository="testsuite" revision="06afa916d4f76e58903bdf133567d28499780f68" Test Trac #8357 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8357#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 14:41:24 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 14:41:24 -0000 Subject: [GHC] #8357: Pretty printing of kind-involving inferred types In-Reply-To: <042.64c49f0a6524a9882ff40c2a141a092f@haskell.org> References: <042.64c49f0a6524a9882ff40c2a141a092f@haskell.org> Message-ID: <057.f00936235f92afa86ef352c777cba914@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:41:59 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:59 -0000

#8357: Pretty printing of kind-involving inferred types -------------------------------------+------------------------------------ Reporter: ksf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Actually I did do the documentation too, in {{{ commit 63f2eee8908e26779c73365ef3c58ade2b73fb6a Author: Simon Peyton Jones <simonpj at microsoft.com> Date: Tue Oct 1 19:18:27 2013 +0100 Documentation for -fprint-explicit-foralls and -fprint-explicit-kinds Plus a tidy-up of the flag documentation in the immediate area docs/users_guide/flags.xml | 175 +++++++++++++++++++++++--------------------- docs/users_guide/using.xml | 41 ++++++++++- 2 files changed, 132 insertions(+), 84 deletions(-) }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8357#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 14:41:43 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 14:41:43 -0000 Subject: [GHC] #8357: Pretty printing of kind-involving inferred types In-Reply-To: <042.64c49f0a6524a9882ff40c2a141a092f@haskell.org> References: <042.64c49f0a6524a9882ff40c2a141a092f@haskell.org> Message-ID: <057.ae823be50099796d3ce22d31c93721ae@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:00 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:00 -0000

#8357: Pretty printing of kind-involving inferred types ---------------------------------------+----------------------------------- Reporter: ksf | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: ghci/scripts/T8357 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by simonpj): * status: new => closed * testcase: => ghci/scripts/T8357 * resolution: => fixed -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8357#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 14:47:37 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 14:47:37 -0000 Subject: [GHC] #8173: GHC uses nub In-Reply-To: <042.ffa88e11c3355b32afa6bc99c33468f4@haskell.org> References: <042.ffa88e11c3355b32afa6bc99c33468f4@haskell.org> Message-ID: <057.97ce04f94f355b1fa6cd2c191daaaf03@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:00 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:00 -0000

#8173: GHC uses nub -------------------------------------+------------------------------------- Reporter: nh2 | Owner: leroux Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Compile-time | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by simonpj): Don't give up so easily :-) Did you look at the amount of heap the compiler ''allocated''? It's easily discoverable (eg use `+RTS -s`, and it's in the nofib logs too, though I don't think `nofib-analyse` looks for it. (You could fix `nofib- analyse` so that it does.) The point is that reducing allocation is almost always good; and it is a FAR more repeatable number than runtime, for which it is hard to measure small differences. My bet is that `ordNub` will be a tiny win in most cases. The other thing is that while using `ordNub` may not benefit typical programs, it may have a dramatic effect on some weird program which happens to produce very long lists for `nub` to digest. Provided using `ordNub` doesn't slow things down for typical programs (use allocation numbers to check) I'm all for using it so that the edge cases don't fall off a cliff. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8173#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 14:49:40 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 14:49:40 -0000 Subject: [GHC] #8390: regression in handling of type variables in constraints on instances which do not appear in the instance head In-Reply-To: <045.f7ebc1e824a1088a68849321bde868cc@haskell.org> References: <045.f7ebc1e824a1088a68849321bde868cc@haskell.org> Message-ID: <060.7354e9e3247663557a429faa83fb2011@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:00 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:00 -0000

#8390: regression in handling of type variables in constraints on instances which do not appear in the instance head ----------------------------------------------+---------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by goldfire): * status: closed => new * resolution: invalid => Comment: Though my head goes a little swimmy when I look at this for too long, I think the ambiguity checker in 7.7 is being overeager here. I can use the `Compose` instance for `Fun` without any type annotations, so therefore, its type is not ambiguous. It seems that the equality constraints on the `F` instance induce what are effectively functional dependencies. Once we know that the first parameter to `Fun` is `F`, we know that the next two must be `Int`. I'm still a little lost as to how to characterize this behavior, and I could understand an argument saying that the ambiguity checker should reject this code. But, we should then also admit that the ambiguity checker is somewhat liberal, rejecting more than is necessary. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8390#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 14:56:02 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 14:56:02 -0000 Subject: [GHC] #8337: make it possible for the user to force orphanness via a module-level annotation In-Reply-To: <044.3b5d98bd39af07453254250d20770b41@haskell.org> References: <044.3b5d98bd39af07453254250d20770b41@haskell.org> Message-ID: <059.35d5b56e9d994360d2e92afc8907206a@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:00 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:00 -0000

#8337: make it possible for the user to force orphanness via a module-level annotation -------------------------------+------------------------------------------- Reporter: errge | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: 7867 | -------------------------------+------------------------------------------- Comment (by simonpj): I'm not sure about this errge. Can't you detect orphan-ness directly? For rules, say, a module is an orphan if it has a RULE for a function that is not defined in this module. So for annotations, could you not say that a module is an orphan if it has annotations for entities (types, classes, functions) that are not defined in this module? Mind you, the [http://www.haskell.org/ghc/docs/latest/html/users_guide /extending-ghc.html#annotation-pragmas manual section on annotations] seems to only allow annotations on things defined in this module. So then ''no'' module is an orphan. I'm pretty confused. More information, and user documentation for this feature, would be helpful. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8337#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 15:13:19 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 15:13:19 -0000 Subject: [GHC] #8390: regression in handling of type variables in constraints on instances which do not appear in the instance head In-Reply-To: <045.f7ebc1e824a1088a68849321bde868cc@haskell.org> References: <045.f7ebc1e824a1088a68849321bde868cc@haskell.org> Message-ID: <060.a44f43cbc3097c7e2b60c7215a9e1198@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:00 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:00 -0000

#8390: regression in handling of type variables in constraints on instances which do not appear in the instance head ----------------------------------------------+---------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by aavogt): goldfire, you're asking for a message `suggested fix: -XAllowAmbiguousTypes'? The reasoning for rejecting the Compose f g instance by default makes sense here. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8390#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 15:34:47 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 15:34:47 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.8301e3c292b638d6c9451541e8d45673@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:00 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:00 -0000

GHC should call GCC with "-Wl,-rpath,<path>":

{{{ % cat test.hs main = putStrLn "Hello" % ghc -fforce-recomp -dynamic test.hs -optl "-Wl,-rpath,/ghc-

#8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by darchon): Replying to [comment:8 kazu-yamamoto]: head/lib/ghc-7.7.20131001/"

% ./test Hello }}} There is the `-fuse-rpaths` flag, perhaps this can be enabled by default on OS X when building an executable? I haven't tested the flag though.

-- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8266#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 16:09:05 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 16:09:05 -0000 Subject: [GHC] #8404: Default to turning on architecture specific optimizations in the codegen Message-ID: <044.264de95b52ceed5babd88d22128d25c7@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:00 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:00 -0000

#8404: Default to turning on architecture specific optimizations in the codegen ------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- LLVM defaults to turning on whatever architecture specific optimizations are supported on the user's machine (e.g. `-msse4.2`). This makes programs run faster during testing and generally gives users a better perception of the compiler. If the user wants to compile for some more portable subset (e.g. when cross-compiling) he/she adds `-march`, `-mcpu`, etc flags on the command line. To implement this we'd have to detect what CPU type is used etc and initialize our `DynFlags` based on that. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8404 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 16:11:15 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 16:11:15 -0000 Subject: [GHC] #8404: Default to turning on architecture specific optimizations in the codegen In-Reply-To: <044.264de95b52ceed5babd88d22128d25c7@haskell.org> References: <044.264de95b52ceed5babd88d22128d25c7@haskell.org> Message-ID: <059.a184eefccfb5c0c63213f6bf45c3d2e3@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:01 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:01 -0000

#8404: Default to turning on architecture specific optimizations in the codegen -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): LLVM documentation about their flags and autodetection behavior here: http://llvm.org/docs/CommandGuide/llc.html -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8404#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 16:25:05 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 16:25:05 -0000 Subject: [GHC] #8390: regression in handling of type variables in constraints on instances which do not appear in the instance head In-Reply-To: <045.f7ebc1e824a1088a68849321bde868cc@haskell.org> References: <045.f7ebc1e824a1088a68849321bde868cc@haskell.org> Message-ID: <060.1e0b5175a8f6f1e85b0f3d04433b429c@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:01 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:01 -0000

#8390: regression in handling of type variables in constraints on instances which do not appear in the instance head ----------------------------------------------+---------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by goldfire): No, not quite. I think that, given that uses of the `Compose` instance work just fine without extra annotations, then that means that the instance is not ambiguous, tautologically by my operating definition of "ambiguous". So, I think we need to choose between these two design alternatives: 1. Permit the instance for `Compose` without `-XAllowAmbiguousTypes`. 2. Admit that the ambiguity checker is over-eager and sometimes rejects code that is unambiguous. Or, I suppose 3. Define ambiguous differently. It's possible that I'm very confused about something here, so if that's the case, please try to enlighten me! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8390#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 16:29:49 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 16:29:49 -0000 Subject: [GHC] #8368: Panic in rejigConRes In-Reply-To: <047.0bdc6d513e37279085cc504ba46ecf14@haskell.org> References: <047.0bdc6d513e37279085cc504ba46ecf14@haskell.org> Message-ID: <062.fa53b363d27a7e7f2d74ed51dd82ded6@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:01 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:01 -0000

#8368: Panic in rejigConRes -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by goldfire): * status: new => patch Comment: I have fixed this, but I am unable to validate, as per [http://www.haskell.org/pipermail/ghc-devs/2013-October/002727.html this email]. If someone wants to validate and push, I'd be grateful. Or, suggest a way I can validate. :) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8368#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 16:36:14 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 16:36:14 -0000 Subject: [GHC] #8390: regression in handling of type variables in constraints on instances which do not appear in the instance head In-Reply-To: <045.f7ebc1e824a1088a68849321bde868cc@haskell.org> References: <045.f7ebc1e824a1088a68849321bde868cc@haskell.org> Message-ID: <060.ec761b738deff599d2c79d883d4276b4@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:01 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:01 -0000

#8390: regression in handling of type variables in constraints on instances which do not appear in the instance head ----------------------------------------------+---------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by simonpj): Consider: {{{ f :: Num a => Int -> Int f = blah instance Num a => C Int where blah }}} Both cases, calling `f` or using the instance, will give rise to an ambiguous constraint `Num a`. So both are rejected in the same way. But functions with an ambiguous times may ''sometimes'' be callable. Eg {{{ class C a b where ... f :: C a b => a -> Int f = blah instance C a b => Eq [a] where blah }}} The type of `f` is ambiguous, in the sense that if we said {{{ g :: C a b => a -> Int -- Identical g = f }}} type checking would fail even. But at ''certain'' types, typechecking might succeed. Example {{{ instance C Char b where blah foo = f 'x' }}} The `-XAllowAmbiguousTypes` flag therefore tells GHC to accept f's type even if it's ambiguous. Thus, GHC's definition of "ambiguous" is "over-eager" in the sense that the function ''can'' be called at some types, although perhaps not at others. Hence the flag. I don't know a less-eager-but-still-useful definition. Certainly, I got lots of Trac tickets before saying "I had a definition f=e; I got ghci to tell me its type; I pasted in that type as a type signature for f, and it didn't typecheck". That was because the inferred type was ambiguous. Same with instance decls. The error message now says {{{ T8390.hs:14:10: Could not deduce (Fun g a b0) arising from the ambiguity check for an instance declaration from the context (Fun f b c, Fun g a b) bound by an instance declaration: (Fun f b c, Fun g a b) => Fun (Compose f g) a c at T8390.hs:14:10-56 The type variable ?b0? is ambiguous In the ambiguity check for: forall f g a c b. (Fun f b c, Fun g a b) => Fun (Compose f g) a c To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the instance declaration for ?Fun (Compose f g) a c? }}} and adding `-XAllowAmbiguousTypes` makes it go through. OK? Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8390#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 16:43:01 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 16:43:01 -0000 Subject: [GHC] #8390: regression in handling of type variables in constraints on instances which do not appear in the instance head In-Reply-To: <045.f7ebc1e824a1088a68849321bde868cc@haskell.org> References: <045.f7ebc1e824a1088a68849321bde868cc@haskell.org> Message-ID: <060.69e36f4d5f62901cec3a21623438a8a5@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:01 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:01 -0000

#8390: regression in handling of type variables in constraints on instances which do not appear in the instance head ----------------------------------------------+---------------------------- Reporter: aavogt | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by goldfire): * status: new => closed * resolution: => invalid Comment: That is option 3, above, fixing my definition of ambiguous. Yes, OK. Many thanks. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8390#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 16:47:43 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 16:47:43 -0000 Subject: [GHC] #8337: make it possible for the user to force orphanness via a module-level annotation In-Reply-To: <044.3b5d98bd39af07453254250d20770b41@haskell.org> References: <044.3b5d98bd39af07453254250d20770b41@haskell.org> Message-ID: <059.f75fb80d28c9536c9609a673fbdd3bce@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:01 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:01 -0000

#8337: make it possible for the user to force orphanness via a module-level annotation -------------------------------+------------------------------------------- Reporter: errge | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: 7867 | -------------------------------+------------------------------------------- Comment (by errge): Yes, annotations are unfortunately local only. My usecase: - WGet.hs imports TCP.hs - TCP.hs defines a commandline flag (via a template haskell function called defineFlag) - called tcp_connect_timeout - this creates a module-level annotation in B.hs, containing all the info about the flag - Main.hs imports WGet.hs only (doesn't import TCP.hs) - Main.hs's main function contains a call to the initProgram splice - this gathers all the flags from all the imported modules transitively - generates a parser - generates a --help output - at runtime run's the parser or reports the usage - TCP and WGet can be in different package, so different compilation unit, not one ghc --make This assumes that Main.hs can reify annotations and module listings, but we're already working on that in #8397 and #8398. For this to work, TCP.hs needs to be orphan, otherwise it's not read by GHC when compiling Main.hs. Now your question: can we somehow figure this out automatically instead of depending on this hacky pragma? The only thing that gives us a clue is that there is a module annotation in TCP.hs. That's all. So I see the following options here: - I change the patch to make modules orphans if they contain module annotations, - I change the patch to have a new type of module annotation (I'm not sure about the syntax though, because e.g. `{-# ANN module orphan "String" #-}` is ambiguous between orphan module annotation of "String" or module annotation of (orphan "String")), - I make the current approach less confusing by explicit documentation and usecase description. In any case, I can of course add the documentation to the manual, I just wanted to get feedback as soon as possible, since we're a bit tight already for 7.8. Now that I gave this some thought, I don't really see why would someone want to reify annotations of values and types without importing them. On the other hand, I see the use case of "orphan" module annotations, so I prefer option 1. What is your opinion? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8337#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 17:34:30 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 17:34:30 -0000 Subject: [GHC] #8402: throwTo segfaults under -prof -threaded -with-rtsopts=N2 In-Reply-To: <043.0ab089710edd4b363b63a9d75aa20e5f@haskell.org> References: <043.0ab089710edd4b363b63a9d75aa20e5f@haskell.org> Message-ID: <058.05844bd03736140b54b54d1387a97bc5@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:01 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:01 -0000

#8402: throwTo segfaults under -prof -threaded -with-rtsopts=N2 ----------------------------------+---------------------------------- Reporter: akio | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Profiling | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by ezyang): Thanks for bringing this to my attention. The relevant commit was for #7747: {{{ commit 1ce57ec9d544beaee79aed50c4e12de144e4482f Author: Edward Z. Yang <ezyang at mit.edu> Date: Thu Mar 7 14:28:54 2013 -0800 Closures must be zeroed even without LDV-profiling. Partially fixes #7747 Signed-off-by: Edward Z. Yang <ezyang at mit.edu> }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8402#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 17:52:29 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 17:52:29 -0000 Subject: [GHC] #8402: throwTo segfaults under -prof -threaded -with-rtsopts=N2 In-Reply-To: <043.0ab089710edd4b363b63a9d75aa20e5f@haskell.org> References: <043.0ab089710edd4b363b63a9d75aa20e5f@haskell.org> Message-ID: <058.1161b8000f8da0af6798ec7d62a98298@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:01 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:01 -0000

#8402: throwTo segfaults under -prof -threaded -with-rtsopts=N2 ----------------------------------+---------------------------------- Reporter: akio | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Profiling | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by ezyang): OK, I understand what is going on here. It useful to think of the various cases that the RTS can be compiled. When the RTS is compiled as profiling and debugging, some of the sanity check code expects closures to be zeroed (specifically checkFullHeap, which explicitly looks for slop like things): {{{ /* skip over slop */ while (p < bd->free && (*p < 0x1000 || !LOOKS_LIKE_INFO_PTR(*p))) { p++; } }}} So we must zero out the slop in that case. However, when RTS is compiled as profiling and multithreaded, as Simon points out (and I didn't realize when making my patch), it's not OK to zero slop when threaded. So Akio's patch prevents the slop from zeroed in this case. Serendipitously, we already had disabled full heap checks when compiling with the threaded RTS. So I think the proper conditional here is: {{{ // It is never valid to overwrite slop when multithreaded #if defined(THREADED_RTS) return; // We need to overwrite slop when: // - We are LDV profiling // - We have a debug RTS which will do full heap checks #elif defined(PROFILING) && !DEBUG if (era <= 0) return; #endif }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8402#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 18:10:16 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 18:10:16 -0000 Subject: [GHC] #8139: ghc 7.6.3 and ghc HEAD fails to build on OS X 10.9 In-Reply-To: <052.92009bd3b6836bd26916c16cd983224b@haskell.org> References: <052.92009bd3b6836bd26916c16cd983224b@haskell.org> Message-ID: <067.9c1250862d900f98c10409cbde839cb0@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:01 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:01 -0000

Replying to [comment:10 george.colpitts]:

Actually, no. This patch fixes problems that occur when building on 10.9 regardless of whether GCC or clang (Xcode 5) are used. In other words, it's not related to Xcode 5 at all.

Building GHC on 10.8 with Xcode 5 does not require this patch. I've already tested this to make sure.

You can see how the patch is applied with the homebrew formula I

#8139: ghc 7.6.3 and ghc HEAD fails to build on OS X 10.9 -------------------------------------+------------------------------------- Reporter: darinmorrison | Owner: darinmorrison Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by george.colpitts): Thanks, sounds like we are all set. Sorry for any confusion I may caused. "The problem" is a bit ambiguous. I was referring to the first of the 3 issues mentioned: gcc is no longer available and the clang compatibility patches of ?http://ghc.haskell.org/trac/ghc/ticket/7678 are not included in 7.6.3. After downloading Xcode 5 onto 10.8 I was unable to install the random-fu package getting errors that seemed the same as those mentioned at ?https://github.com/mxcl/homebrew/issues/20546, particularly those of dhess "GHC uses the system's C preprocessor, and Clang can't parse CPP directives that split lines. A similar problem occurs when compiling certain Haskell libraries (e.g., cereal) on 10.8 using the Xcode 5 DP and Homebrew-installed GHC." Replying to [comment:11 darinmorrison]: maintain here:

https://github.com/darinmorrison/homebrew-

haskell/blob/master/Formula/ghc.rb -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8139#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 19:15:23 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 19:15:23 -0000 Subject: [GHC] #8368: Panic in rejigConRes In-Reply-To: <047.0bdc6d513e37279085cc504ba46ecf14@haskell.org> References: <047.0bdc6d513e37279085cc504ba46ecf14@haskell.org> Message-ID: <062.cbf754a2ca982f482ce4a2d8c8507a06@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:02 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:02 -0000

#8368: Panic in rejigConRes -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by monoidal): @goldfire: It passes validate, except for some perf tests which failed previously. Do you want this trace? It is visible during normal build of ghc. {{{ pprTrace "RAE1" (vcat [ppr tmpl_tvs, ppr res_tmpl, ppr dc_tvs, ppr res_ty]) $ }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8368#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 19:23:20 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 19:23:20 -0000 Subject: [GHC] #8368: Panic in rejigConRes In-Reply-To: <047.0bdc6d513e37279085cc504ba46ecf14@haskell.org> References: <047.0bdc6d513e37279085cc504ba46ecf14@haskell.org> Message-ID: <062.aa2b64466bab60724f9441747ebdad67@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:02 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:02 -0000

#8368: Panic in rejigConRes -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): Yikes, no! Thanks for catching that -- searching for my initials is one of my internal steps during validation, which I obviously skipped. I just checked, and that should be the only one to remove. Thanks! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8368#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 20:02:46 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 20:02:46 -0000 Subject: [GHC] #8368: Panic in rejigConRes In-Reply-To: <047.0bdc6d513e37279085cc504ba46ecf14@haskell.org> References: <047.0bdc6d513e37279085cc504ba46ecf14@haskell.org> Message-ID: <062.ca8c34f6a393563854e3abe85af91421@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:02 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:02 -0000

#8368: Panic in rejigConRes -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Krzysztof Gogolewski ): In [changeset:0c7d2d7507b9e4dca24c159c0bfcce9de7b233c4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0c7d2d7507b9e4dca24c159c0bfcce9de7b233c4" Fix Trac #8368. Two different fixes were necessary here. First, we need to fail eagerly in kcConDecl, to prevent the return-type error in tcConDecl from firing twice. (This wasn't caught earlier because of the eager fail in the datatype kind-checking code -- which isn't used for data instances!) We also must check again in tcDataFamInstDecl, because it's possible for a data instance return type to have the right head but the wrong body (i.e., doesn't conform to the data instance type patterns). This check is only possible *after* desugaring from HsType to Type, so it can't be done in tcConRes with the first check. This is documented in a comment at check_valid_data_con, a local function within tcDataFamInstDecl. }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8368#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 20:03:38 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 20:03:38 -0000 Subject: [GHC] #8368: Panic in rejigConRes In-Reply-To: <047.0bdc6d513e37279085cc504ba46ecf14@haskell.org> References: <047.0bdc6d513e37279085cc504ba46ecf14@haskell.org> Message-ID: <062.d4512b80d161869ae37fc37c2f4c8afe@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:02 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:02 -0000

#8368: Panic in rejigConRes -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Krzysztof Gogolewski ): In [changeset:e3e28cd65cea30a59e65a824b816f1a81ff46174/testsuite]: {{{ #!CommitTicketReference repository="testsuite" revision="e3e28cd65cea30a59e65a824b816f1a81ff46174" New tests for #8368. }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8368#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 20:05:44 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 20:05:44 -0000 Subject: [GHC] #8368: Panic in rejigConRes In-Reply-To: <047.0bdc6d513e37279085cc504ba46ecf14@haskell.org> References: <047.0bdc6d513e37279085cc504ba46ecf14@haskell.org> Message-ID: <062.5846f307daad70e848ef1a503ea36d44@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:02 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:02 -0000

#8368: Panic in rejigConRes -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by monoidal): * status: patch => closed * resolution: => fixed Comment: Done! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8368#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 20:08:32 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 20:08:32 -0000 Subject: [GHC] #8368: Panic in rejigConRes In-Reply-To: <047.0bdc6d513e37279085cc504ba46ecf14@haskell.org> References: <047.0bdc6d513e37279085cc504ba46ecf14@haskell.org> Message-ID: <062.62bb31b111bb16826425d57fcf2a04e5@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:02 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:02 -0000

#8368: Panic in rejigConRes -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | goldfire Priority: normal | Status: Component: Compiler | closed Resolution: fixed | Milestone: Operating System: Unknown/Multiple | Version: 7.7 Type of failure: None/Unknown | Keywords: Test Case: indexed- | Architecture: types/should_fail/{T8368,T8368a} | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by goldfire): * testcase: => indexed-types/should_fail/{T8368,T8368a} Comment: Thanks, monoidal, for doing the last leg of the fix. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8368#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 20:16:16 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 20:16:16 -0000 Subject: [GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?) In-Reply-To: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> References: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> Message-ID: <062.bfaf6a92173b96f66d0f0c06a481d481@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:02 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:02 -0000

#7602: Threaded RTS performing badly on recent OS X (10.8?) -----------------------------------+---------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 7678 Blocking: | Related Tickets: -----------------------------------+---------------------------------- Changes (by george.colpitts): * cc: george.colpitts@?, simonmar (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7602#comment:28 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 21:32:36 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 21:32:36 -0000 Subject: [GHC] #8402: throwTo segfaults under -prof -threaded -with-rtsopts=N2 In-Reply-To: <043.0ab089710edd4b363b63a9d75aa20e5f@haskell.org> References: <043.0ab089710edd4b363b63a9d75aa20e5f@haskell.org> Message-ID: <058.81b7e2b716e73da5772e2e7bbe1ed067@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:02 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:02 -0000

#8402: throwTo segfaults under -prof -threaded -with-rtsopts=N2 ----------------------------------+---------------------------------- Reporter: akio | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Profiling | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by akio): Should it be allowed to use LDV profiling with {{{-threaded}}} and {{{-N1}}}? I assumed the answer was "yes", because the CPP condition that controls the definition of {{{OVERWRITING_CLOSURE}}} was {{{ #if defined(PROFILING) || (!defined(THREADED_RTS) && defined(DEBUG)) }}} which evaluates to true in {{{thr_p}}}. The only case this is useful seemed when you are doing LDV profiling with {{{-threaded}}} but with {{{-N1}}}. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8402#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 21:39:22 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 21:39:22 -0000 Subject: [GHC] #8402: throwTo segfaults under -prof -threaded -with-rtsopts=N2 In-Reply-To: <043.0ab089710edd4b363b63a9d75aa20e5f@haskell.org> References: <043.0ab089710edd4b363b63a9d75aa20e5f@haskell.org> Message-ID: <058.bc58a431861d69e315adfa263729d410@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:03 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:03 -0000

#8402: throwTo segfaults under -prof -threaded -with-rtsopts=N2 ----------------------------------+---------------------------------- Reporter: akio | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Profiling | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by ezyang): If that's the case, then checkGeneration in rts/sm/Sanity.c should be adjusted, because it means that we can do a full heap check on all GCs when `-N1`. I don't know if LDV is supposed to work with the threaded runtime. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8402#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 21:53:34 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 21:53:34 -0000 Subject: [GHC] #8367: putStrLn and related printing functions don't output to MinTTY properly under Windows In-Reply-To: <046.2951117840610b0c0519f1700567b124@haskell.org> References: <046.2951117840610b0c0519f1700567b124@haskell.org> Message-ID: <061.3b5e46462c584241d063ff89da3030cd@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:03 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:03 -0000

#8367: putStrLn and related printing functions don't output to MinTTY properly under Windows ----------------------------+---------------------------------------------- Reporter: schyler | Owner: schyler Type: bug | Status: new Priority: high | Milestone: Component: Runtime | Version: 7.6.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Moderate (less than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | ----------------------------+---------------------------------------------- Changes (by schyler): * cc: schyler, simonmar (added) * difficulty: Unknown => Moderate (less than a day) * owner: => schyler * priority: normal => high -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8367#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 22:25:25 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 22:25:25 -0000 Subject: [GHC] #8173: GHC uses nub In-Reply-To: <042.ffa88e11c3355b32afa6bc99c33468f4@haskell.org> References: <042.ffa88e11c3355b32afa6bc99c33468f4@haskell.org> Message-ID: <057.76aa175ad33140e9f25246a4e803a85b@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:03 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:03 -0000

Did you look at the amount of heap the compiler allocated? It's easily discoverable (eg use +RTS -s, and it's in the nofib logs too, though I > don't think nofib-analyse looks for it. (You could fix nofib-analyse so

#8173: GHC uses nub -------------------------------------------------+------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time performance bug | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by leroux): * owner: leroux => * difficulty: Moderate (less than a day) => Unknown * status: closed => new * resolution: wontfix => * priority: normal => low Comment: that it does.) I'm working on fixing nofib-analyse up so that we can extract compile allocation info. Thanks for the motivation, SPJ! =) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8173#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 22:25:36 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 22:25:36 -0000 Subject: [GHC] #8173: GHC uses nub In-Reply-To: <042.ffa88e11c3355b32afa6bc99c33468f4@haskell.org> References: <042.ffa88e11c3355b32afa6bc99c33468f4@haskell.org> Message-ID: <057.d0336cea645fb4ca34048e11eb91514d@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:03 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:03 -0000

#8173: GHC uses nub -------------------------------------------------+------------------------- Reporter: nh2 | Owner: Type: bug | leroux Priority: low | Status: new Component: Compiler | Milestone: Resolution: | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: Type of failure: Compile-time performance bug | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by leroux): * owner: => leroux -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8173#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 22:33:49 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 22:33:49 -0000 Subject: [GHC] #8405: experiment with using function-sections for linking (for smaller libs and executables) Message-ID: <045.ff128453c9ddce6d07b91486f573635a@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:03 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:03 -0000

#8405: experiment with using function-sections for linking (for smaller libs and executables) ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- currently the only support we have for making small (ish) executables using split objects, which 1. is not on by default, for various good reasons 2. can seriously penalize compile times 3. in tandem, something like strip is often used, but on some platforms/targets (such as the iOS cross compiler), strip will actually break things might be worth seriously experimenting with function-sections / gc- sections in the object files we generate. example slide deck on this http://elinux.org/images/2/2d/ELC2010-gc- sections_Denys_Vlasenko.pdf -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8405 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 22:52:26 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 22:52:26 -0000 Subject: [GHC] #8133: T7881 fails with hpc In-Reply-To: <048.d4c9ab8af9d3e92fc15f081b5dea0f7c@haskell.org> References: <048.d4c9ab8af9d3e92fc15f081b5dea0f7c@haskell.org> Message-ID: <063.10bb0ed42b4d6e2183abccbf8cd11e2f@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:03 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:03 -0000

#8133: T7881 fails with hpc ----------------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Code Coverage | Version: 7.7 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by monoidal): * status: new => closed * resolution: => fixed Comment: It was fixed with #8384. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8133#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 3 22:54:49 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Oct 2013 22:54:49 -0000 Subject: [GHC] #8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault In-Reply-To: <046.a1de52e736c53bf94deece978e2702d5@haskell.org> References: <046.a1de52e736c53bf94deece978e2702d5@haskell.org> Message-ID: <061.391010a71905c3c2aff7eedd17a88690@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:03 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:03 -0000

#8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------+---------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by igloo): Or better yet, have the functions that do dynamic loading give an error if not compiled for the appropriate way. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8376#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 00:47:39 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 00:47:39 -0000 Subject: [GHC] #8139: ghc 7.6.3 and ghc HEAD fails to build on OS X 10.9 In-Reply-To: <052.92009bd3b6836bd26916c16cd983224b@haskell.org> References: <052.92009bd3b6836bd26916c16cd983224b@haskell.org> Message-ID: <067.78e6e064fb885ee53ad46481199b56ff@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:03 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:03 -0000

#8139: ghc 7.6.3 and ghc HEAD fails to build on OS X 10.9 -------------------------------------+------------------------------------- Reporter: darinmorrison | Owner: darinmorrison Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by darinmorrison): Replying to [comment:13 george.colpitts]:

Thanks, sounds like we are all set. Sorry for any confusion I may caused.

No worries :] If you're still trying to get it to work, I'd suggest trying the homebrew tap I pointed to (http://github.com/darinmorrison/homebrew-haskell). It should "just work" on 10.8 and 10.9 with or without Xcode 5. Another option is to download the existing bindist from the GHC website and edit the SETTINGS file in the source tree. In that case, you'd have to change "C Compiler Command" to something other than "gcc" (which now points to clang). If it were me, I'd either just use the apple-gcc42 or gcc49 from homebrew. Modifying this entry in SETTINGS will fix random breakage when building Haskell packages with the bindist (caused by GHC using clang for CPP). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8139#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 01:01:44 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 01:01:44 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.9156ee7daa8e5394dfe9298f35e67993@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:03 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:03 -0000

#8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by kazu-yamamoto): Thanks. I'm now building GHC with such a hack. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8266#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 04:16:42 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 04:16:42 -0000 Subject: [GHC] #8406: Invalid object in isRetainer() or Segfault Message-ID: <047.cda95cb1752355077595406288b06592@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:03 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:03 -0000

#8406: Invalid object in isRetainer() or Segfault ----------------------------------+---------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- When compiling with -rtsopts -threaded -prof -fprof-auto -caf-all and running with -N4 -hr I get a "Segmentation fault" every time. If I run with -N4 -qg1 -hr, I either get a segfault or internal error: Invalid object in isRetainer(): 40 When the segfault happens, it happens quickly. If the segfault doesn't happen, the program runs for about 5 seconds and I get "invalid object" error (always 40). Without -hr, I have never gotten a segfault. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8406 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 04:18:35 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 04:18:35 -0000 Subject: [GHC] #8400: Migrate the RTS to use libuv (or libev, or libevent) In-Reply-To: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> References: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> Message-ID: <061.2cb54989946693a45c74ccaf6dd9564b@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:03 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:03 -0000

#8400: Migrate the RTS to use libuv (or libev, or libevent) ----------------------------+---------------------------------------------- Reporter: schyler | Owner: simonmar Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Project (more than a week) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: 635, 7353 Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by schyler): Wouldn't it be faster to move all of the I/O stuff into the RTS as C and then only end up back in haskell-land when fd stuff is finished? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8400#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 04:20:20 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 04:20:20 -0000 Subject: [GHC] #8406: Invalid object in isRetainer() or Segfault In-Reply-To: <047.cda95cb1752355077595406288b06592@haskell.org> References: <047.cda95cb1752355077595406288b06592@haskell.org> Message-ID: <062.8760181329c6713116ec21a3fde1a69c@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:04 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:04 -0000

#8406: Invalid object in isRetainer() or Segfault ----------------------------------+---------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by crockeea): I forgot to point out that if I don't specify either of "-N4" or "-qg1" (but still compile with -threaded), the program runs as expected and does not crash. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8406#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 04:44:55 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 04:44:55 -0000 Subject: [GHC] #8400: Migrate the RTS to use libuv (or libev, or libevent) In-Reply-To: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> References: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> Message-ID: <061.dad4f04d8bb2e8f71e41319a2149a7a1@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:04 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:04 -0000

Wouldn't it be faster to move all of the I/O stuff into the RTS as C and

#8400: Migrate the RTS to use libuv (or libev, or libevent) ----------------------------+---------------------------------------------- Reporter: schyler | Owner: simonmar Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Project (more than a week) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: 635, 7353 Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by tibbe): Replying to [comment:4 schyler]: then only end up back in haskell-land when an fd event is finished? As I mentioned do *something* in the RTS instead of in a separate Haskell thread is probably going to be somewhat faster than what we do today.

In this case, libuv is probably appropriate.

It will likely not work, as libuv want to own the thread to drive the event loop. The scheduler needs to own the thread for it to work. Perhaps we could run libuv in a separate thread like we do with the I/O manager today. I also don't know if libuv is thread safe. We most likely want to make some assumptions/optimizations based on our special needs and I'm not sure if libuv can support that efficiently. In the end performance will probably be best if we call the underlying system calls directly. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8400#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 05:14:23 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 05:14:23 -0000 Subject: [GHC] #8400: Migrate the RTS to use libuv (or libev, or libevent) In-Reply-To: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> References: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> Message-ID: <061.25f31752a83d5439f4d5596b09969c46@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:04 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:04 -0000

#8400: Migrate the RTS to use libuv (or libev, or libevent) ----------------------------+---------------------------------------------- Reporter: schyler | Owner: simonmar Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Project (more than a week) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: 635, 7353 Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by thoughtpolice): I think there are separate discussions happening here. One is about moving to libuv because it provides some nice abstractions we don't have to roll ourselves, and it works on Windows - and the other is about moving the scheduler and related stuff around for better I/O performance. These are somewhat separate discussions, IMO. To move the I/O manager into the RTS (and port it from C to Haskell) would be a sizeable amount of complex work, everything else aside (it's much, much easier to get all the tricky multicore stuff right in Haskell, obviously!) Of course this shouldn't kill the suggestion, but it's worth bringing this up - it adds a sizeable amount of complexity to an already extremely complex thing (the RTS.) It also adds other tradeoffs. This isn't a thing we're new to - we often carry the complexity burden for users - but we also don't want to totally overblow our complexity budget. Frankly I think we should look into improvements beyond "totally rewrite it in C" - this should be a last resort only, unless some numbers would suggest huge order-of-magnitude improvements. For windows, #7353 discusses some of the issues with Joey's I/O manager, the main one being that it needs some sort of scheduler integration to help mitigate the performance loss from round-tripping through the kernel on every I/O request. I can definitely buy that scheduler integration may help latency numbers on all platforms. There's also the somewhat-related issue that `-threaded` always adds a bit of latency anyway, and the Mio paper touches on this. Perhaps we should do a more thorough investigation and experiments first. And also, Joey really just wanted interruptible socket timeouts. Perhaps as a first step, we should: A) investigate if Joey's patches in #7353 can be resurrected, perhaps as a library (his work happened before the introduction of Mio!) and B) see if there's performance on the table. There's probably some scope for this if we can find a talented Windows engineer to run some good numbers. If A) can happen at least, and the improvements are stable, I may not be opposed to integrating this I/O manager into `base`, provided Simon thinks it's OK. Although bad performance may be unfortunate, it also brings feature parity to windows in this area (which was woefully limited in other ways.) As for the other stuff libuv provides - we already tend to have very lightweight wrappers around most system concurrency primitives so I'm not sure how much we need it, but being maintained and less code for us is a win too. (But I don't find this to be too much of a selling point to us, personally. Just a unified interface to IOCP/epoll/kqueue is enough if we were to use it.) Not to deter anyone, I just find the discussion here touching on a few related things, and it's all quite a lot to consider and think about! I think there's a ton of scope for improvement here, but it seems quite open ended in terms of design and implementation. Performance numbers and patches welcome! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8400#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 05:39:52 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 05:39:52 -0000 Subject: [GHC] #8406: Invalid object in isRetainer() or Segfault In-Reply-To: <047.cda95cb1752355077595406288b06592@haskell.org> References: <047.cda95cb1752355077595406288b06592@haskell.org> Message-ID: <062.b414aa983ecca3f3baec4bd187af6de0@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:04 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:04 -0000

#8406: Invalid object in isRetainer() or Segfault ----------------------------------+---------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by thoughtpolice): Does this happen for all programs, or only a specific one? Can you provide a small testcase, if possible? Thanks! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8406#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 05:42:37 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 05:42:37 -0000 Subject: [GHC] #8406: Invalid object in isRetainer() or Segfault In-Reply-To: <047.cda95cb1752355077595406288b06592@haskell.org> References: <047.cda95cb1752355077595406288b06592@haskell.org> Message-ID: <062.5096dea8d1725f9b2c65ad65bc93959c@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:04 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:04 -0000

#8406: Invalid object in isRetainer() or Segfault ----------------------------------+---------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by crockeea): It just happened for one program I'm profiling at the moment. It's quite large, so I may not be able to get a small test case. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8406#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 06:31:12 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 06:31:12 -0000 Subject: [GHC] #8400: Migrate the RTS to use libuv (or libev, or libevent) In-Reply-To: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> References: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> Message-ID: <061.16b18bbc721eadf4e22db92991643917@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:05 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:05 -0000

#8400: Migrate the RTS to use libuv (or libev, or libevent) ----------------------------+---------------------------------------------- Reporter: schyler | Owner: simonmar Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Project (more than a week) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: 635, 7353 Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by tibbe): I generally agree with thoughtpolice's comments. At this point I don't think we will get much further without building a prototype or two. I think moving the I/O manager into the scheduler can also remove some complexity: * We now have a bunch of Haskell-side global state that could live more naturally on the capability data structure. * The synchronization situation would be a bit simpler inside the RTS (and there would be one less thread). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8400#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 07:33:29 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 07:33:29 -0000 Subject: [GHC] #8407: Module re-exports at the package level Message-ID: <046.6085f09a4062c5bfb3a91dbc96472039@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:05 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:05 -0000

From ghc-devs at haskell.org Fri Oct 4 07:35:38 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 07:35:38 -0000 Subject: [GHC] #8405: experiment with using function-sections for

From ghc-devs at haskell.org Fri Oct 4 07:37:28 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 07:37:28 -0000 Subject: [GHC] #8405: experiment with using function-sections for

#8407: Module re-exports at the package level ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- For various package reorganization purposes, especially for possibly turning `base` into a shim package that re-exports some modules from more specialized packages, good support for module re-exports would be nice. I wrote up a design spec at ModuleReexports; this bug is to track the progress. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8407 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler linking (for smaller libs and executables) In-Reply-To: <045.ff128453c9ddce6d07b91486f573635a@haskell.org> References: <045.ff128453c9ddce6d07b91486f573635a@haskell.org> Message-ID: <060.29e9bb653e3ef9adb40910dfab492ffc@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:05 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:05 -0000 #8405: experiment with using function-sections for linking (for smaller libs and executables) -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by refold): * cc: the.dead.shall.rise@? (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8405#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler linking (for smaller libs and executables) In-Reply-To: <045.ff128453c9ddce6d07b91486f573635a@haskell.org> References: <045.ff128453c9ddce6d07b91486f573635a@haskell.org> Message-ID: <060.c7c0d97cecdf0a971a5da37c88823deb@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:05 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:05 -0000 #8405: experiment with using function-sections for linking (for smaller libs and executables) -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by refold): 4. Apparently doesn't work with `-fllvm` (#8300) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8405#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 08:28:40 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 08:28:40 -0000 Subject: [GHC] #8400: Migrate the RTS to use libuv (or libev, or libevent) In-Reply-To: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> References: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> Message-ID: <061.f04b9280a9abae7ee121aff2973df9a7@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:05 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:05 -0000

#8400: Migrate the RTS to use libuv (or libev, or libevent) ----------------------------+---------------------------------------------- Reporter: schyler | Owner: simonmar Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Project (more than a week) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: 635, 7353 Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by simonmar): Agree with everything that @thoughtpolice said. Also, I'm not generally swayed by arguments of the form "we should use library X because it is actively maintained and does job Y that we already do", because external dependencies have their own costs - let's not forget we've had problems with all of gmp, libffi and LLVM. There are benefits to being in control of your own code, and when the functionality already exists and works (as in the case of the rts code) it's an unforced change. These things are never black and white, and we have to weigh up any benefits we might get against the costs of incurring an external dependency. I just want to point out that we shouldn't add new dependencies without thinking very carefully. @tibbe: I suggest first identifying the problem that would be solved by moving the I/O manager into the RTS. Identify where we have extra latency, and explain why it can't be solved in Haskell. Moving the I/O manager wholesale into the RTS is a huge job, because you don't get to take advantage of nice things like atomicModifyIORef and immutable data structures, and the interaction with the scheduler is likely to be very tricky indeed. There would need to be significant payoff. Adding small hooks is a better approach, if we can find out what hooks would help - e.g. per-thread state is something we don't have a good way to do right now, and would be a generally useful thing to add. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8400#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 08:55:09 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 08:55:09 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.361422caf6a6318d335dbad610cf65fc@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:05 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:05 -0000

#8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by darchon): I've updated my patch so that executables built by ghc now get an rpath link to ghc's `topDir`: https://gist.github.com/christiaanb/6822676 I think the behaviour on OS X and Linux is now almost the same: * Linux: multiple absolute rpath's to all the dependent package directories * OS X: single rpath; relative, rpath-referencing, locations for GHC- installed packages; absolute locations for user-installed packages Perhaps a future version of GHC could have an even more desirable situation on OS X: * two rpaths: user/cabal location and ghc location * All libraries locations are relative, rpath-referencing This would make distribution of a dynamically-linked OS X binary easier, as you would only need to add extra rpath(s) for the location of the dependent packages. This would require an update in Cabal however, as it needs to add the second rpath to the executable. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8266#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 08:57:58 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 08:57:58 -0000 Subject: [GHC] #8400: Migrate the RTS to use libuv (or libev, or libevent) In-Reply-To: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> References: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> Message-ID: <061.df05d6a2698dffdf6439f061ae8792a2@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:05 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:05 -0000

#8400: Migrate the RTS to use libuv (or libev, or libevent) ----------------------------+---------------------------------------------- Reporter: schyler | Owner: simonmar Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Project (more than a week) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: 635, 7353 Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by simonpj): For what it's worth, my gut feel is that we should be moving fuctionality out of the monolithic RTS written in C, and into Haskell libraries. Moving the I/O manager into the RTS would be a move in the opposite direction. It could conceivably be the right thing to do, but my nose tell me otherwise. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8400#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 09:00:50 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 09:00:50 -0000 Subject: [GHC] #8407: Module re-exports at the package level In-Reply-To: <046.6085f09a4062c5bfb3a91dbc96472039@haskell.org> References: <046.6085f09a4062c5bfb3a91dbc96472039@haskell.org> Message-ID: <061.5dfc01126e21485f0daac26f37b5cd44@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:05 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:05 -0000

#8407: Module re-exports at the package level -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): This is primarily a Cabal question, isn't it? If Cabal wants to move this way, I'd be happy for GHC to move to accommodate. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8407#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 09:03:24 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 09:03:24 -0000 Subject: [GHC] #8407: Module re-exports at the package level In-Reply-To: <046.6085f09a4062c5bfb3a91dbc96472039@haskell.org> References: <046.6085f09a4062c5bfb3a91dbc96472039@haskell.org> Message-ID: <061.c2d4de717fba064b4492d66037d06391@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:05 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:05 -0000

#8407: Module re-exports at the package level -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): I?ll open appropriate tickets against Cabal and haddock if there is consensus that the proposal is useful and the syntax and semantics are agreed on ? currently, this is just a draft. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8407#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 09:05:33 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 09:05:33 -0000 Subject: [GHC] #2184: if findExecutable finds a file that matchs the argument, check if it is an executable In-Reply-To: <043.14945e7e7a44f91d6d7e77f4c5d2fcfb@haskell.org> References: <043.14945e7e7a44f91d6d7e77f4c5d2fcfb@haskell.org> Message-ID: <058.70c7a22abcce922b99acdd70c2c3541e@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:05 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:05 -0000

#2184: if findExecutable finds a file that matchs the argument, check if it is an executable -------------------------------------+------------------------------------- Reporter: iago | Owner: leroux Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: | Version: 6.8.2 libraries/directory | Keywords: findExecutable Resolution: | check executable Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by simonpj): * priority: normal => high * milestone: 7.6.2 => 7.8.1 Comment: I know nothing about this, but I'll milestone it for 7.8.1 so that Austin is sure to review it. Austin: I'm not expressing an opinion, but could you look at this since we have a patch offered? Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/2184#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 09:51:52 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 09:51:52 -0000 Subject: [GHC] #6084: Add stg_ap_pnnv and related call patterns In-Reply-To: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> References: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> Message-ID: <064.75d4bd9f436ade27b9cf6c277f9103ef@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:06 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:06 -0000

#6084: Add stg_ap_pnnv and related call patterns -------------------------------------+------------------------------------ Reporter: SimonMeier | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 8313 | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * cc: simonmar (added) Comment: Simon M and I have agreed to commit this patch. However, there are times when we KNOW that the runtime fast-patch check will fail: {{{ f x y = e foo = ...map (f 3).... }}} In `foo` we'll generate a `SlowCall` to `f`, and there is no point in doing a runtime evaluated-ness and arity check on `f` because we can see statically that it's under-saturated. (Indeed ideally we'd have a RTS entry for known-under-saturated calls.) Or maybe we never ''have'' under- saturated known functions, because core-to-STG eta-expands it. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/6084#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 09:53:50 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 09:53:50 -0000 Subject: [GHC] #8311: suboptimal code generated for even :: Int -> Bool by NCG (x86, x86_64) In-Reply-To: <047.86e8206e31b6dc590c59487f4d1109a7@haskell.org> References: <047.86e8206e31b6dc590c59487f4d1109a7@haskell.org> Message-ID: <062.2eca5911c2076776c8bc6aa6e90e0a7a@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:06 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:06 -0000

#8311: suboptimal code generated for even :: Int -> Bool by NCG (x86, x86_64) -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * cc: simonmar (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8311#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 09:54:49 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 09:54:49 -0000 Subject: [GHC] #8311: suboptimal code generated for even :: Int -> Bool by NCG (x86, x86_64) In-Reply-To: <047.86e8206e31b6dc590c59487f4d1109a7@haskell.org> References: <047.86e8206e31b6dc590c59487f4d1109a7@haskell.org> Message-ID: <062.f8c16b86b88612edc245087faf55fa12@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:06 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:06 -0000

From ghc-devs at haskell.org Fri Oct 4 10:05:07 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 10:05:07 -0000 Subject: [GHC] #8405: experiment with using function-sections for

#8311: suboptimal code generated for even :: Int -> Bool by NCG (x86, x86_64) -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Could you give us the source Haskell code, and how you compiled it, that gives this sub-optimal result? Thanks! Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8311#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler linking (for smaller libs and executables) In-Reply-To: <045.ff128453c9ddce6d07b91486f573635a@haskell.org> References: <045.ff128453c9ddce6d07b91486f573635a@haskell.org> Message-ID: <060.ec3b47133de473d557dd8b845483e0b2@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:06 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:06 -0000 #8405: experiment with using function-sections for linking (for smaller libs and executables) -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by refold): Looks like --gc-sections is not supported on Windows: http://sourceware.org/bugzilla/show_bug.cgi?id=11539 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8405#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 13:56:52 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 13:56:52 -0000 Subject: [GHC] #8400: Migrate the RTS to use libuv (or libev, or libevent) In-Reply-To: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> References: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> Message-ID: <061.4eac07676c821016cb49a93cc5a3e1e0@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:06 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:06 -0000

#8400: Migrate the RTS to use libuv (or libev, or libevent) ----------------------------+---------------------------------------------- Reporter: schyler | Owner: simonmar Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Project (more than a week) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: 635, 7353 Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Changes (by AndreasVoellmy): * cc: andreas.voellmy@? (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8400#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 14:28:12 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 14:28:12 -0000 Subject: [GHC] #8311: suboptimal code generated for even :: Int -> Bool by NCG (x86, x86_64) In-Reply-To: <047.86e8206e31b6dc590c59487f4d1109a7@haskell.org> References: <047.86e8206e31b6dc590c59487f4d1109a7@haskell.org> Message-ID: <062.185ecb8dcf371812deff8814f51c98d9@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:06 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:06 -0000

#8311: suboptimal code generated for even :: Int -> Bool by NCG (x86, x86_64) -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rwbarton): The source of that code is in GHC.Real in base, but for reproducing, use this: {{{ module Even where myEven :: Int -> Bool myEven n = n `rem` 2 == 0 }}} compiled with `ghc -O2 -o Even.o -c Even.hs`. The LLVM backend (`ghc -O2 -fllvm -o Even.o -c Even.hs`) does produce a `testb $0x1,0x3(%esi)` instruction. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8311#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 14:40:26 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 14:40:26 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.5871509aa85afa315018e8833e9c3ba2@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:06 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:06 -0000

#7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): By default I'm now suppressing the kind arguments. But the problem is still there, as you'll see if you use `-fprint-explicit-kinds`. The trouble is that it's hard to build the `TyCon`s with pretty kind varaibles. When converting to `IfaceSyn` we do pretty-ify them (because interface files work on `OccNames`). So a viable approach would be, in the `info` command, to convert to `IfaceSyn` (using the existing code in `MkIface`) and then print that. I think this would be quite straightforward, but the printing stuff used by GHCi would need to be adapted to use `IfaceSyn` instead. Would anyone care to try this? Simple but a bit fiddly. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7730#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 14:42:24 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 14:42:24 -0000 Subject: [GHC] #8263: allow duplicate deriving / standalone deriving In-Reply-To: <045.bba713620ff6c6ed638444c7e9f46806@haskell.org> References: <045.bba713620ff6c6ed638444c7e9f46806@haskell.org> Message-ID: <060.742a55def76c3d409e72595b2a3dd0e0@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:06 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:06 -0000

#8263: allow duplicate deriving / standalone deriving -------------------------------------+------------------------------------ Reporter: aavogt | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): I'd rather not. It's another rule to implement and document in the manual. Why not put `deriving Typeable` on the declaration of `Flag`? Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8263#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 15:40:47 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 15:40:47 -0000 Subject: [GHC] #8320: Build fails due to Haddock error in ghc-prim:GHC.Types In-Reply-To: <044.d03a5005166332b97ad3b025d8d241c6@haskell.org> References: <044.d03a5005166332b97ad3b025d8d241c6@haskell.org> Message-ID: <059.9caa7d465410f363f57b3229ca3e1b50@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:06 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:06 -0000

#8320: Build fails due to Haddock error in ghc-prim:GHC.Types ----------------------------------------+--------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by simonpj): darchon, can you still reproduce this? If so, can you send a complete log, showing the command line you used, for a 'make' without using -j? And do enable the interface-tracing code as you show above. Thanks Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8320#comment:23 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 16:03:19 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 16:03:19 -0000 Subject: [GHC] #8299: Add richer data model address arithmetic: AddrDiff and AddrInt (ie d Int_ptr_diff and Int_ptr_size) In-Reply-To: <045.f91b5080e44be46bd4f6c2cd9b6ce680@haskell.org> References: <045.f91b5080e44be46bd4f6c2cd9b6ce680@haskell.org> Message-ID: <060.c971574a80fde6afa93ea39b47368bee@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:06 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:06 -0000

#8299: Add richer data model address arithmetic: AddrDiff and AddrInt (ie d Int_ptr_diff and Int_ptr_size) ----------------------------+---------------------------------------------- Reporter: carter | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.6.3 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Project (more than a week) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: 8287 | ----------------------------+---------------------------------------------- Comment (by carter): Reid Barton (who's been experimenting with an x32 ABI) made an observation yesterday evening on IRC #ghc about address vs int sizes for ghc {{{ [09:24:34] <rwbarton> ugh, I didn't think about the fact that integer- gmp exposes its representation to the world [09:24:43] <rwbarton> that means potentially anybody is assuming that Int is the same size as mp_limb_t [09:24:47] dcoutts_: fwiw, bytestring w/ ghc-head/linux/i386 passed too [09:55:47] <rwbarton> I guess ghcjs has the same problem [09:56:07] <rwbarton> can't support exporting the J# constructor [09:56:25] rwbarton: what problem exactly? [09:57:11] <rwbarton> so my problem that I just realized is on x32 [09:57:34] <rwbarton> where Int is 4 bytes, but gmp uses 8 byte limbs [09:57:59] <rwbarton> I can't have people going around constructing Integers with J#, because first of all they might not provide a ByteArray# that's a multiple of 8 bytes long [09:59:49] <rwbarton> so ideally (for me) there would be a type with the S# and J# constructors for pattern matching on, that was distinct from Integer [10:00:14] <rwbarton> that former type exported, the constructors of Integer not exported [10:00:29] <rwbarton> with conversions between them that on "ordinary" platforms are zero-cost [10:04:34] rwbarton: btw, I've been wishing for some bignum- only type [10:04:45] i.e. an Integer only w/ J# [10:05:38] then the proper Integer type could use that unboxed as single field in its J# constructor }}} This is just another data point to consider in any design constraints -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8299#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 16:09:55 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 16:09:55 -0000 Subject: [GHC] #8263: allow duplicate deriving / standalone deriving In-Reply-To: <045.bba713620ff6c6ed638444c7e9f46806@haskell.org> References: <045.bba713620ff6c6ed638444c7e9f46806@haskell.org> Message-ID: <060.3a0b38f40290201f2ce55331474e1371@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:06 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:06 -0000

#8263: allow duplicate deriving / standalone deriving -------------------------------------+------------------------------------ Reporter: aavogt | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by aavogt): Flag comes from cabal: that deriving (Typeable) was added in version 1.18. No code is needed to support that version. Things get messy to support older versions of Cabal which do not export a Typeable instance. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8263#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 16:21:52 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 16:21:52 -0000 Subject: [GHC] #8406: Invalid object in isRetainer() or Segfault In-Reply-To: <047.cda95cb1752355077595406288b06592@haskell.org> References: <047.cda95cb1752355077595406288b06592@haskell.org> Message-ID: <062.373cf79779e0c960c66b8b9b564e4148@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:06 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:06 -0000

#8406: Invalid object in isRetainer() or Segfault ----------------------------------+---------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by bgamari): * cc: bgamari@? (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8406#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 16:24:33 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 16:24:33 -0000 Subject: [GHC] #7867: Allow template-haskell to communicate with itself between compilation units through the interface file In-Reply-To: <044.7393523543fe94ac1b36b652004b6974@haskell.org> References: <044.7393523543fe94ac1b36b652004b6974@haskell.org> Message-ID: <059.0808ce633a572490d85fb63d16ac5a77@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:06 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:06 -0000

#7867: Allow template-haskell to communicate with itself between compilation units through the interface file --------------------------+------------------------------------------------ Reporter: errge | Owner: Type: | Status: patch feature request | Milestone: 7.8.1 Priority: | Version: 7.6.3 normal | Keywords: Component: | Architecture: Unknown/Multiple Template Haskell | Difficulty: Easy (less than 1 hour) Resolution: | Blocked By: 3725, 8337, 8340, 8397, 8398 Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | --------------------------+------------------------------------------------ Comment (by simonpj): errge, I've been talking to Austin It's very late in the day for 7.8, and we are still discussing the ''design''. So I don't think we can put this in 7.8, otherwise we'll mess it up and/or commit to a design that we subsequently regret. Can you start a GHC Trac wiki page to describe clearly * The use-case you have in mind. Along the lines you have given recently in #8337, but can you give a small concrete example? I still don't get it; for example, is `tcp_connect_timeout` exported, and if not what good is it? * The programmer's-eye view of the design (eg the TH API changes). For example, I'm very dubious about `qReifyModules` because the notion of the "list of modules that are known to the compiler" is such an ill-defined one. Imagine if you were writing a new Haskell compiler: how would you implement that API? What is its actual semantics? * A sketch of the implementation changes needed (and links to tickets) That would help more people participate in the conversation. At the moment you are implementing solutions to problems that we don't understand! Thanks Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7867#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 17:39:01 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 17:39:01 -0000 Subject: [GHC] #8281: The impossible happened: primRepToFFIType In-Reply-To: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> References: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> Message-ID: <059.3bc566768601a87090d4a29ee4275137@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:07 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:07 -0000

#8281: The impossible happened: primRepToFFIType ---------------------------------------+----------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by simonpj): * cc: simonmar (added) Comment: I see what is happening here, but need help from Simon M or anyone else. Here's what I learned: * `ThreadId#` is represented by a heap pointer; it's "rep" is `PtrRep`. But it is a primitive type; i.e. not implemented in Haskell. * The totally-undocumented flag `-XUnliftedFFITypes` seems to allow all of GHC's primitive types to be marshalled across the FFI. * These primitive types include `Array#`, `MutableArray#`, `ByteArray#` and `MutableByteArray#`, all of which also have `PtrRep`. * Marshalling these pointer types seems utterly wrong for a '''safe''' call, where GC might occur during the call, thereby moving the array. (Or maybe arrays never move? If so, this is un-documented.) * The actual crash comes in `LibFFI.hsc`, in `primRepToFFIType` which is used (via `prepForeignCall`) only by the bytecode generator, to prepare the foreign call arguments. `primRepToFFIType` barfs if it gets a `PtrRep`. * How does it work for `Array#` and friends? Because have a special shim in `ByteCodeGen.generateCCall`, which adds an offset to get past the array header, and then says `AddrRep`! Hence `primRepToFFIType` sees an `AddrRep`. * There is no such special treatment for `ThreadId#`, hence the crash. * The base-library module `GHC.Conc.Sync` has precisely the `rts_getThreadId` import as in the tiny test case above, but works(just) because it is compiled. My conclusion: * These `PtrRep` things should not be allowed in '''safe''' foreign calls. * In `primRepToFFIType` we should allow `PtrRep` However I'm not certain about the last of these because I don't understand how foreign calls work in the bytecode interpreter. Simon M: do you agree? Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8281#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 18:16:03 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 18:16:03 -0000 Subject: [GHC] #8383: "tagToEnum# (0# ==# 1#) :: Bool" causes CASEFAIL in ghci In-Reply-To: <047.66d6e6666fd83ab68f57c227d806c7ae@haskell.org> References: <047.66d6e6666fd83ab68f57c227d806c7ae@haskell.org> Message-ID: <062.1d2c7b3f5308380071aa3a59bbb76d89@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:07 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:07 -0000

From ghc-devs at haskell.org Fri Oct 4 18:16:09 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 18:16:09 -0000 Subject: [GHC] #8134: ghc enters a loop while building 7.6.3 for

#8383: "tagToEnum# (0# ==# 1#) :: Bool" causes CASEFAIL in ghci ---------------------------------+---------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+---------------------------------- Comment (by Simon Peyton Jones ): In [changeset:a9649c48681054d86b6a1e33118aa12903a4fbfd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a9649c48681054d86b6a1e33118aa12903a4fbfd" Fix the bytecode genreation for tagToEnum# (Trac #8383) Reid Barton's diagnosis was right on the mark, though the fix wasn't quite right. See Note [Implementing tagToEnum#]. As usual I did some refactoring. }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8383#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler powerpc64 platform. In-Reply-To: <043.0289be94f89f3f22e5a1a6cc61dcce1b@haskell.org> References: <043.0289be94f89f3f22e5a1a6cc61dcce1b@haskell.org> Message-ID: <058.cf5c5db6db51e8d588d54268b4cfedc9@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:07 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:07 -0000 #8134: ghc enters a loop while building 7.6.3 for powerpc64 platform. -------------------------------------+----------------------------- Reporter: k0da | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.3 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+----------------------------- Comment (by trommler): Replying to [comment:7 juhpetersen]:

Still not completely sure if this is a ghc or glibc issue or some conflict between them. Apparently the pthread handling on non-intel glibc is different from intel platforms. But we don't see the issue on PowerPC 32 bit, which is registerized and has a native code generator. PowerPC 64 is unregisterized.

-- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8134#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 18:17:08 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 18:17:08 -0000 Subject: [GHC] #8383: "tagToEnum# (0# ==# 1#) :: Bool" causes CASEFAIL in ghci In-Reply-To: <047.66d6e6666fd83ab68f57c227d806c7ae@haskell.org> References: <047.66d6e6666fd83ab68f57c227d806c7ae@haskell.org> Message-ID: <062.c64fc4a595639e6b486a297201485375@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:07 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:07 -0000

#8383: "tagToEnum# (0# ==# 1#) :: Bool" causes CASEFAIL in ghci ---------------------------------+---------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+---------------------------------- Comment (by Simon Peyton Jones ): In [changeset:4b16eaa10cf0e42700d9559b462d7d61c11b86c3/testsuite]: {{{ #!CommitTicketReference repository="testsuite" revision="4b16eaa10cf0e42700d9559b462d7d61c11b86c3" Test Trac #8383 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8383#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 21:03:17 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 21:03:17 -0000 Subject: [GHC] #8199: Get rid of HEAP_ALLOCED In-Reply-To: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> References: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> Message-ID: <060.69e11839e4aafa80bbdc494385de11c8@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:07 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:07 -0000

#8199: Get rid of HEAP_ALLOCED ----------------------------+---------------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Project (more than a week) Operating System: | Blocked By: 5435 Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by ezyang): Haven't done the GHC tests yet, but over ICFP I realized I hadn't run the GC nofib tests. They look really good: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- circsim +5.5% +0.0% -1.3% -1.4% +0.0% constraints +5.5% +0.0% -3.6% -3.6% +0.0% fibheaps +5.5% +0.0% -1.0% -1.0% +0.0% fulsom +5.7% +0.0% -1.1% -1.0% +3.0% gc_bench +5.5% +0.0% -1.0% -1.0% +0.0% happy +5.9% +0.0% -0.3% -0.3% -0.3% hash +5.5% +0.0% -4.7% -4.6% +0.1% lcss +5.5% +0.0% -7.2% -7.2% +0.0% mutstore1 +5.5% +0.0% -1.5% -1.5% +0.0% mutstore2 +5.5% +0.0% -3.3% -3.4% +0.0% power +5.5% +0.0% -2.4% -2.9% -1.0% spellcheck +7.4% +0.0% -6.5% -6.5% +0.0% -------------------------------------------------------------------------------- Min +5.5% +0.0% -7.2% -7.2% -1.0% Max +7.4% +0.0% -0.3% -0.3% +3.0% Geometric Mean +5.7% +0.0% -2.9% -2.9% +0.1% }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8199#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 21:55:53 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 21:55:53 -0000 Subject: [GHC] #1201: ghci runs Template Haskell splices 4 times In-Reply-To: <044.6dd33d366d8a02b3db5c895a0994c7e6@haskell.org> References: <044.6dd33d366d8a02b3db5c895a0994c7e6@haskell.org> Message-ID: <059.0c0a7f4988166ccd52fdb363b38048df@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:08 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:08 -0000

#1201: ghci runs Template Haskell splices 4 times -------------------------------------+------------------------------------ Reporter: igloo | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: _|_ Component: Template Haskell | Version: 6.6 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: ghci018 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Geoffrey Mainland ): In [changeset:26eaf88810ec11a9ac5c0095d38ecad89b4485fc/testsuite]: {{{ #!CommitTicketReference repository="testsuite" revision="26eaf88810ec11a9ac5c0095d38ecad89b4485fc" Update test to reflect fix for #1201. Splices are now run in the renamer instead of the type checker, so they only get run once. }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/1201#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 22:56:37 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 22:56:37 -0000 Subject: [GHC] #8048: Register spilling produces ineffecient/highly contending code In-Reply-To: <046.812a6c0f95e2954ecf561f3e19f7d22f@haskell.org> References: <046.812a6c0f95e2954ecf561f3e19f7d22f@haskell.org> Message-ID: <061.70d10f633898f500a7e933615bb8e945@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:08 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:08 -0000

#8048: Register spilling produces ineffecient/highly contending code -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: bug | Status: new Priority: high | Milestone: _|_ Component: Compiler | Version: 7.6.3 Resolution: | Keywords: register Operating System: Unknown/Multiple | allocator spill Type of failure: Runtime | Architecture: Unknown/Multiple performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by schyler): * priority: normal => high -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8048#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 22:57:31 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 22:57:31 -0000 Subject: [GHC] #8259: HEAD won't build on Windows In-Reply-To: <046.1934b122fb654bf934d36ee5820b9caf@haskell.org> References: <046.1934b122fb654bf934d36ee5820b9caf@haskell.org> Message-ID: <061.4fe3823545d11d4b363560f47c53f8ed@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:08 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:08 -0000

#8259: HEAD won't build on Windows -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 7.7 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by schyler): * status: new => closed * resolution: => fixed -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8259#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 22:58:41 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 22:58:41 -0000 Subject: [GHC] #8260: Parallel build behaves erratic under Windows In-Reply-To: <046.1ed6b1bfa779421c5dc5841d497e0fb8@haskell.org> References: <046.1ed6b1bfa779421c5dc5841d497e0fb8@haskell.org> Message-ID: <061.38a142b995ec64e882914c4fd6ec35d5@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:08 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:08 -0000

#8260: Parallel build behaves erratic under Windows ----------------------------------------+---------------------------------- Reporter: schyler | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 7.7 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by schyler): * status: new => closed * resolution: => fixed Comment: The mailing list suggested using MSYS2, which has a working make w/ -j. This seems to resolve the problem. http://sourceforge.net/projects/msys2/ Since this isn't really a GHC bug, I'm closing it. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8260#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 22:59:12 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 22:59:12 -0000 Subject: [GHC] #8297: Allow implicit parameters to take a default value In-Reply-To: <046.83de0442d66d57dde8079b4e8339312b@haskell.org> References: <046.83de0442d66d57dde8079b4e8339312b@haskell.org> Message-ID: <061.b452ccd0fade4621823583487d5d012e@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:09 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:09 -0000

#8297: Allow implicit parameters to take a default value ----------------------------+---------------------------------------------- Reporter: schyler | Owner: Type: feature | Status: new request | Milestone: _|_ Priority: low | Version: Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Changes (by schyler): * priority: normal => low -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8297#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 4 23:02:14 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Oct 2013 23:02:14 -0000 Subject: [GHC] #8115: GHC 64-bit Windows build failures with LLVM In-Reply-To: <046.85b4ba291c9a7177535aee44db08c94a@haskell.org> References: <046.85b4ba291c9a7177535aee44db08c94a@haskell.org> Message-ID: <061.f4acb245c5ca0eb4b628a3b646f9b715@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:09 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:09 -0000

#8115: GHC 64-bit Windows build failures with LLVM ---------------------------------+------------------------------------ Reporter: schyler | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Changes (by schyler): * priority: normal => high Comment: Given -fllvm is a pretty important feature of GHC, I'm promoting this to high. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8115#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 00:10:46 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 00:10:46 -0000 Subject: [GHC] #8408: Ambiguity in TH reify based on compilation method Message-ID: <044.3017443dfaccd9131ca33cba42500d5d@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:09 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:09 -0000

#8408: Ambiguity in TH reify based on compilation method ------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The attached tar.gz contains a simple example where compiling with --make results in a different semantics than compiling all the modules with -c and then linking them together. This is shown by build.sh, so just start by running that. The ambiguity comes from the fact that the compiler is not starting the compilation of modules with a clean slate when using --make. This can be seen in compiler/iface/LoadIface.lhs line 276. I'm not sure if/how we should do anything about this urgently. Just wanted to note down this ambiguity, so we know it's there and can care about fixing it if we want to. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8408 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 00:29:20 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 00:29:20 -0000 Subject: [GHC] #8048: Register spilling produces ineffecient/highly contending code In-Reply-To: <046.812a6c0f95e2954ecf561f3e19f7d22f@haskell.org> References: <046.812a6c0f95e2954ecf561f3e19f7d22f@haskell.org> Message-ID: <061.eabb845f0ccee8747b34b19c370bbb48@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:09 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:09 -0000

#8048: Register spilling produces ineffecient/highly contending code -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 7.6.3 Resolution: | Keywords: register Operating System: Unknown/Multiple | allocator spill Type of failure: Runtime | Architecture: Unknown/Multiple performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by carter): * priority: high => normal Comment: Schyler, do you have a engineering plan of attack to resolve the problem? Do you have some example codes where you can share benchmarks on the ticket that demonstrate this actually creates a performance problem? I remember you saying you did, but also that you said later "register renaming on newer CPUs seems to make the problem go away". Is it an actual performance issue, or merely an aesthetical one? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8048#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 00:48:18 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 00:48:18 -0000 Subject: [GHC] #7867: Allow template-haskell to communicate with itself between compilation units through the interface file In-Reply-To: <044.7393523543fe94ac1b36b652004b6974@haskell.org> References: <044.7393523543fe94ac1b36b652004b6974@haskell.org> Message-ID: <059.5e3f9c7017805f3bfa1e7858b6db3999@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:09 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:09 -0000

#7867: Allow template-haskell to communicate with itself between compilation units through the interface file --------------------------+------------------------------------------------ Reporter: errge | Owner: Type: | Status: patch feature request | Milestone: 7.8.1 Priority: | Version: 7.6.3 normal | Keywords: Component: | Architecture: Unknown/Multiple Template Haskell | Difficulty: Easy (less than 1 hour) Resolution: | Blocked By: 3725, 8337, 8340, 8397, 8398 Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | --------------------------+------------------------------------------------ Comment (by errge): Simon, first of all thanks for your reply. I'll do the wikipage, but in the meantime I'd like to clear up some confusion by answering your specific questions and giving further pointers. * What you miss is that `tcp_connect_timeout` is useful without being exported, because it can be used INSIDE the TCP module. Namely in the `connectToTCP :: Host -> Port -> IO ()` method. That method can simply refer to the current flag value by `flags_tcp_connect_timeout`. The user doesn't have to implement any passing of the value from Main through WGet to TCP, like in other getopt libraries. Please read these for further clarification: 1. http://www.haskell.org/pipermail/haskell- cafe/2012-April/099641.html 2. http://blog.risko.hu/2012/04/ann-hflags-0.html 3. https://github.com/errge/hflags/blob/master/examples/package/test/main.hs, https://github.com/errge/hflags/blob/master/examples/package/TupMain.hs, https://github.com/errge/hflags/blob/master/examples/package/Tup.hs * You're right about qReifyModules, that's maybe the most shaky part of this. I actually don't like the current way how this is handled inside GHC, but I'm quite sure that I don't see enough to judge this. Currently GHC slurps up interface files and then uses them all while compiling different source files with --make. This results in the ill-definedness you are talking about, but this is unfortunately already visible via the TH API, in #8408 I show that with a concrete example. Let's discuss this in #8398, maybe we can come up with a better definition for module listing, I'll give it a try over the weekend to implement a better patch. I'm all in for implementing this feature slowly and cleanly for a future release if not for 7.8, right about that. My end goal is to have the right and general compiler features, so the maintenance burden is minimal on me too regarding hflags and new GHC versions :) On the other hand, I'd really like to have a working hflags as soon as I can: by using dirty tricks internally inside hflags (like communicating via instances instead of annotations). The only missing puzzle piece that I desperatly need support for from the compiler is to make a module orphan from TH. Currently I can do this by generating a fake orphan rule, but that would generate a warning for the user when compiling with -Wall, I'd like to have a warningless way. Can we maybe come up with a design/solution just for #8337 that is small and easy enough to be surely not messed up or regretted later? I still prefer option 1, stating that module anntations make a module orphan seems pretty harmless, but useful from my point of view. The patch would be also some clean and concise. I'll report back here when the more general summarizing wikipage that you asked for is ready and then we can continue to work on the more difficult changes for annotation reification and module listing in a more principled way. Can the already merged patches for #3725 and #8340 stay, please? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7867#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 02:07:52 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 02:07:52 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.4e2445475d5eeeee313c34f92164209b@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:09 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:09 -0000

#8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by kazu-yamamoto): Great! https://gist.github.com/christiaanb/6822676 fixes everything! Please merge. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8266#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 02:13:36 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 02:13:36 -0000 Subject: [GHC] #8320: Build fails due to Haddock error in ghc-prim:GHC.Types In-Reply-To: <044.d03a5005166332b97ad3b025d8d241c6@haskell.org> References: <044.d03a5005166332b97ad3b025d8d241c6@haskell.org> Message-ID: <059.a9e17bab1296773eec604eb19721f003@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:09 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:09 -0000

#8320: Build fails due to Haddock error in ghc-prim:GHC.Types ----------------------------------------+--------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by kazu-yamamoto): On 32bit Linux, I got the following error today: {{{ make -r --no-print-directory -f ghc.mk phase=final all "/home/kazu/work/ghc/inplace/bin/haddock" --odir="libraries/ghc-prim/dist- install/doc/html/ghc-prim" --no-tmp-comp-dir --dump-interface=libraries /ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock --html --hoogle --title="ghc-prim-0.3.1.0: GHC primitives" --prologue="libraries/ghc-prim /dist-install/haddock-prologue.txt" --optghc=-hisuf --optghc=dyn_hi --optghc=-osuf --optghc=dyn_o --optghc=-hcsuf --optghc=dyn_hc --optghc=-fPIC --optghc=-dynamic --optghc=-H32m --optghc=-O --optghc =-package-name --optghc=ghc-prim-0.3.1.0 --optghc=-hide-all-packages --optghc=-i --optghc=-ilibraries/ghc-prim/. --optghc=-ilibraries/ghc-prim /dist-install/build --optghc=-ilibraries/ghc-prim/dist- install/build/autogen --optghc=-Ilibraries/ghc-prim/dist-install/build --optghc=-Ilibraries/ghc-prim/dist-install/build/autogen --optghc=-Ilibraries/ghc-prim/. --optghc=-optP-include --optghc=-optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h --optghc=-package --optghc=rts-1.0 --optghc=-package-name --optghc=ghc- prim --optghc=-XHaskell98 --optghc=-XCPP --optghc=-XMagicHash --optghc=-XForeignFunctionInterface --optghc=-XUnliftedFFITypes --optghc=-XUnboxedTuples --optghc=-XEmptyDataDecls --optghc=-XNoImplicitPrelude --optghc=-O2 --optghc=-no-user-package-db --optghc=-rtsopts --optghc=-odir --optghc=libraries/ghc-prim/dist- install/build --optghc=-hidir --optghc=libraries/ghc-prim/dist- install/build --optghc=-stubdir --optghc=libraries/ghc-prim/dist- install/build libraries/ghc-prim/./GHC/Classes.hs libraries/ghc- prim/./GHC/CString.hs libraries/ghc-prim/./GHC/Debug.hs libraries/ghc- prim/./GHC/Magic.hs libraries/ghc-prim/dist- install/build/GHC/PrimopWrappers.hs libraries/ghc-prim/./GHC/IntWord64.hs libraries/ghc-prim/./GHC/Tuple.hs libraries/ghc-prim/./GHC/Types.hs libraries/ghc-prim/dist-install/build/autogen/GHC/Prim.hs +RTS -tlibraries /ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock.t --machine- readable Haddock coverage: Warning: Couldn't find .haddock for export GHC.Prim.Int64# Warning: Couldn't find .haddock for export GHC.Prim.Word64# 3% ( 1 / 38) in 'GHC.IntWord64' 80% ( 8 / 10) in 'GHC.Types' 17% ( 1 / 6) in 'GHC.CString' 3% ( 2 / 63) in 'GHC.Tuple' 0% ( 0 / 3) in 'GHC.Debug' 0% ( 0 /366) in 'GHC.PrimopWrappers' 72% (817 /1138) in 'GHC.Prim' 100% ( 3 / 3) in 'GHC.Magic' 38% ( 6 / 16) in 'GHC.Classes' attempting to use module ?ghc-prim:GHC.Types? (libraries/ghc- prim/./GHC/Types.hs) which is not loaded make[1]: *** [libraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc- prim.haddock] Error 1 make: *** [all] Error 2 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8320#comment:24 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 03:40:36 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 03:40:36 -0000 Subject: [GHC] #8297: Allow implicit parameters to take a default value In-Reply-To: <046.83de0442d66d57dde8079b4e8339312b@haskell.org> References: <046.83de0442d66d57dde8079b4e8339312b@haskell.org> Message-ID: <061.a55d4e911927df4cf75d7b8b1e163367@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:09 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:09 -0000

#8297: Allow implicit parameters to take a default value ----------------------------+---------------------------------------------- Reporter: schyler | Owner: Type: feature | Status: closed request | Milestone: _|_ Priority: low | Version: Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: invalid | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Changes (by carter): * status: new => closed * resolution: => invalid Comment: this seems more a case for using the convention of having a function with a default config, and a more general version that takes a config record, rather than requiring implicit parameters, which are in some sense a way to do dynamic scoping (which is unrelated to type holes) eg {{{ sieve :: In -> Out sieveWithConfig :: In -> Config -> Out }}} i'm closing this for now, because there doesn't seem to be a strong use case that isn't covered by the *WithConfig idiom. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8297#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 07:17:45 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 07:17:45 -0000 Subject: [GHC] #8409: nofib-analyse Message-ID: <045.8888a02d96d1846d8871fbe468aa0f72@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:09 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:09 -0000

Did you look at the amount of heap the compiler allocated? It's easily discoverable (eg use +RTS -s, and it's in the nofib logs too, though I don't think nofib-analyse looks for it. (You could fix nofib-analyse so

#8409: nofib-analyse -------------------------------------------+------------------------------- Reporter: leroux | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: NoFib benchmark suite | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- In response to comment:13:ticket:8173: that it does.) Teach nofib to include allocation info (from module compilation time). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8409 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 07:18:42 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 07:18:42 -0000 Subject: [GHC] #8409: nofib-analyse: compile allocations (was: nofib-analyse) In-Reply-To: <045.8888a02d96d1846d8871fbe468aa0f72@haskell.org> References: <045.8888a02d96d1846d8871fbe468aa0f72@haskell.org> Message-ID: <060.3343f35db0f62119d8a63e45393912aa@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:09 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:09 -0000

#8409: nofib-analyse: compile allocations -------------------------------------+------------------------------------- Reporter: leroux | Owner: leroux Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: NoFib benchmark | Version: 7.6.3 suite | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: None/Unknown | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by leroux): * owner: => leroux -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8409#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 07:20:57 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 07:20:57 -0000 Subject: [GHC] #8409: nofib-analyse: compile allocations In-Reply-To: <045.8888a02d96d1846d8871fbe468aa0f72@haskell.org> References: <045.8888a02d96d1846d8871fbe468aa0f72@haskell.org> Message-ID: <060.9ea6e99b3167050b3b91352ce8f2dc5b@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:09 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:09 -0000

#8409: nofib-analyse: compile allocations -------------------------------------+------------------------------------- Reporter: leroux | Owner: leroux Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: NoFib benchmark | Version: 7.6.3 suite | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: None/Unknown | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by leroux): * status: new => patch Comment: Since this is the first time I'm touching the nofib benchmarking suite, it'd be tremendously helpful if someone could meticulously review the patch I've attached (attachment:nofib-compile-time-allocation.patch). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8409#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 07:23:28 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 07:23:28 -0000 Subject: [GHC] #8410: NCG sometimes produces code like `addl $0 ...` Message-ID: <046.2854eeaf7af4358eb88b52c987f62d1e@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:10 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:10 -0000

#8410: NCG sometimes produces code like `addl $0 ...` ------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- See the haskell and ASM output; https://gist.github.com/kvanberendonck/6837792 Search for `addl $0` in your browser and you'll see a couple occurrences. This is a useless instruction. It would be a minor optimization to not emit these. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8410 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 07:35:58 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 07:35:58 -0000 Subject: [GHC] #8173: GHC uses nub In-Reply-To: <042.ffa88e11c3355b32afa6bc99c33468f4@haskell.org> References: <042.ffa88e11c3355b32afa6bc99c33468f4@haskell.org> Message-ID: <057.7b05be4aa92063971739cd00876a32a0@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:10 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:10 -0000

#8173: GHC uses nub -------------------------------------------------+------------------------- Reporter: nh2 | Owner: Type: bug | leroux Priority: low | Status: new Component: Compiler | Milestone: Resolution: | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: Type of failure: Compile-time performance bug | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by leroux): I've attached a patch to include compile time alloc info on #8409. I'll keep digging in but so far it doesn't look like allocation is affected significantly either. {{{ Compile Allocations ------------------------------------------------------------------------------- Program head-0 head-1 ordNub-0 ordNub-1 ordNub-cases-0 ordNub-cases-1 ------------------------------------------------------------------------------- -1 s.d. ----- -0.0% -0.0% -0.0% -0.0% -0.0% +1 s.d. ----- +0.0% +0.0% +0.0% +0.0% +0.0% Average ----- +0.0% +0.0% +0.0% +0.0% +0.0% }}} 0% across the board, apparently. Any other suggestions anyone? Perhaps I'll try to replace the few `nub`'s I left laying around in the compiler. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8173#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 09:14:16 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 09:14:16 -0000 Subject: [GHC] #8320: Build fails due to Haddock error in ghc-prim:GHC.Types In-Reply-To: <044.d03a5005166332b97ad3b025d8d241c6@haskell.org> References: <044.d03a5005166332b97ad3b025d8d241c6@haskell.org> Message-ID: <059.638aa7ade4071481d70da69ae100198f@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:10 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:10 -0000

#8320: Build fails due to Haddock error in ghc-prim:GHC.Types ----------------------------------------+--------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by darchon): It's still failing with the same error (latest commit: d5075dcfecbab1b6e3dbb7f8347124923796d46b) My complete build log: https://www.dropbox.com/s/c8ndh4x2jwtm4n1/build.log [[BR]] The interesting part: http://lpaste.net/93924 [[BR]] My build.mk: http://lpaste.net/93925 (`perf` build without profiling libs) The command that I used to built are: {{{ make maintainer-clean ./sync-all pull perl boot ./configure make }}} However, I did patch the intree haddock (`utils/haddock`) to get the extra interface-tracing information. You can find the patch I applied here: https://gist.github.com/christiaanb/6837931. The first part of the patch fixes a bug related to staticFlags (#8276), the second part adds the interface-tracing DynFlag. Anyhow, I looked at the part of the code that prints the error message, and it seems to print it when you want to read the interface file of a module in the HomePackage; an interface of a module it expects to be already read/loaded. The reason it got to that part of the code is because the interface info for the wired-in thing ([] in this case) was neither in the HomePackageTable (HPT), nor in the PIT. But since I don't know what either of those things are, nor what assertions should hold for them in relation to wired-in things, I couldn't analyse the bug any further. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8320#comment:25 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 11:54:34 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 11:54:34 -0000 Subject: [GHC] #4385: Type-level natural numbers In-Reply-To: <047.cc0a64c6c51b4985aaaaf093ec247386@haskell.org> References: <047.cc0a64c6c51b4985aaaaf093ec247386@haskell.org> Message-ID: <062.a1555f08f8d111c4f0122be5e9eeb344@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:10 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:10 -0000

#4385: Type-level natural numbers --------------------------------------------+------------------------------ Reporter: diatchki | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler (Type checker) | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by nsch): * cc: mail@? (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/4385#comment:64 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 11:59:44 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 11:59:44 -0000 Subject: [GHC] #8411: TypeSynonymInstances with partial type Message-ID: <042.08643ec9c49892b1ffcde20daa6f8b76@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:10 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:10 -0000

#8411: TypeSynonymInstances with partial type ----------------------------+---------------------------------------------- Reporter: wvv | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects valid program Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- TypeSynonymInstances allow only full synonyms. With {{{ {-# LANGUAGE TypeSynonymInstances #-} type RTuple b a = (a, b) instance Monad (RTuple b) where ... -- or instance Monad (RTuple b :: * -> *) where ... }}} I got next error: {{{ test.hs:17:22: Type synonym `RevTuple' should have 2 arguments, but has been given 1 In the instance declaration for `Monad (RTuple b :: * -> *)' }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8411 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 13:57:19 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 13:57:19 -0000 Subject: [GHC] #8412: TH allows negative type-level integers Message-ID: <047.68a9bececbb7f0d86cec5b7c41950825@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:10 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:10 -0000

#8412: TH allows negative type-level integers -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHC accepts Difficulty: Easy (less than 1 | invalid program hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Similar to #8306, it is possible to create type-level -1 via {{{ type T = $(return $ LitT $ NumTyLit (-1)) }}} Easy to fix with new TH by moving the check from parser to renamer. I'm preparing a patch. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8412 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 15:07:10 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 15:07:10 -0000 Subject: [GHC] #8413: testsuite: Allow to skip performance tests Message-ID: <046.054ac5c3ea1b0378aebbab7cc9439b5d@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:10 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:10 -0000

#8413: testsuite: Allow to skip performance tests ------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: feature request | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- More often than not the output of the performance tests is in the way, rather than helping, or simply not relevant at a certain time of development (e.g. after changing some error message generating code in the compiler). It would be nice to have a way to skip such tests. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8413 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 15:08:45 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 15:08:45 -0000 Subject: [GHC] #8413: testsuite: Allow to skip performance tests In-Reply-To: <046.054ac5c3ea1b0378aebbab7cc9439b5d@haskell.org> References: <046.054ac5c3ea1b0378aebbab7cc9439b5d@haskell.org> Message-ID: <061.273ab0c33ba2ee68dc04933ad8a78d8e@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:10 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:10 -0000

#8413: testsuite: Allow to skip performance tests -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: feature request | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * status: new => patch Comment: Patch for review in branch `wip/T8413`; I?d like to hear a second ?ok? instead before pushing the changes. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8413#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 15:22:45 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 15:22:45 -0000 Subject: [GHC] #8410: NCG sometimes produces code like `addl $0 ...` In-Reply-To: <046.2854eeaf7af4358eb88b52c987f62d1e@haskell.org> References: <046.2854eeaf7af4358eb88b52c987f62d1e@haskell.org> Message-ID: <061.2541d29e739bb9738786f7d6db61983c@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:10 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:10 -0000

#8410: NCG sometimes produces code like `addl $0 ...` -------------------------------------+------------------------------------ Reporter: schyler | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by rwbarton): * status: new => closed * resolution: => fixed Comment: This is fixed already in HEAD, hooray. (And for anyone planning to reproduce this, it only affected i386, not amd64, for this particular program.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8410#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 15:27:24 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 15:27:24 -0000 Subject: [GHC] #8412: TH allows negative type-level integers In-Reply-To: <047.68a9bececbb7f0d86cec5b7c41950825@haskell.org> References: <047.68a9bececbb7f0d86cec5b7c41950825@haskell.org> Message-ID: <062.fc707fd32fbb4e3c6e883af36d71b9f7@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:10 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:10 -0000

#8412: TH allows negative type-level integers -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHC accepts | Difficulty: Easy (less than 1 invalid program | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => patch -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8412#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 15:46:19 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 15:46:19 -0000 Subject: [GHC] #8276: Building Haddock documentation panics with perf build on x86_64 Linux In-Reply-To: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> References: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> Message-ID: <063.3463dda6f2964d4b14d582eff75a5f87@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:11 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:11 -0000

#8276: Building Haddock documentation panics with perf build on x86_64 Linux ---------------------------------------+---------------------------------- Reporter: jstolarek | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Documentation | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by thoughtpolice): * owner: => thoughtpolice * priority: high => highest * milestone: => 7.8.1 Comment: I'll be looking into this. After talking about it, me and SPJ are honestly just inclined to delete the whole save/restore static flag code, since it doesn't really seem like it works anyway (re: Simon M's point #1 above, regarding the CAFs that cannot be reset.) This doesn't change the reality of #2 though: with GHCi being dynamic, `v_opt_C_ready` will already be set in GHCi, since we only use one copy of the GHC package. But this would completely eliminate this problem, although DocTest needs to be updated then. I attempted to begin removing the remaining static flags, but it quickly got extremely painful - removing the last ones will require quite a bit of refactoring as changing them to `DynFlag` entries makes the changes extremely pervasive (leaking into the wired-ins API, for example.) Simon H, neither of us really understood what DocTest needs this for - to run `createInterfaces` several times apparently, but I'm not sure what the implications of that are. The remaining static flags only control very basic things, meant mostly for debugging - why does DocTest require saving them, exactly? Do you have a better suggestion of what should happen? Because this must be fixed, and I'm inclined to just delete broken code, rather than paper around it with more odd behavior that's difficult to comprehend. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8276#comment:28 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 15:54:12 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 15:54:12 -0000 Subject: [GHC] #5987: Too many symbols in ghc package DLL In-Reply-To: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> References: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> Message-ID: <059.55cd01f65dfd2f3a994320204ee87001@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:11 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:11 -0000

#5987: Too many symbols in ghc package DLL -------------------------------------+------------------------------------ Reporter: igloo | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 3658 | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * owner: => thoughtpolice -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/5987#comment:24 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 15:54:26 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 15:54:26 -0000 Subject: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 In-Reply-To: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> References: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> Message-ID: <063.bc32867e9cf73d48557aaed76dd5a858@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:11 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:11 -0000

#7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------+---------------------------------- Changes (by thoughtpolice): * cc: hvr (added) * owner: => thoughtpolice -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7134#comment:30 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 15:54:34 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 15:54:34 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.c2977ab4d508fe99b343e2f0883813c6@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:11 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:11 -0000

#8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | thoughtpolice Priority: highest | Status: patch Component: Build System | Milestone: 7.8.1 Resolution: | Version: 7.7 Operating System: MacOS X | Keywords: Type of failure: GHC doesn't work at all | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by thoughtpolice): * owner: => thoughtpolice -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8266#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 15:54:52 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 15:54:52 -0000 Subject: [GHC] #2725: Remove Hack in compiler/nativeGen/MachCodeGen.hs In-Reply-To: <046.d67fe0f29d3ab9719210cf02d0142851@haskell.org> References: <046.d67fe0f29d3ab9719210cf02d0142851@haskell.org> Message-ID: <061.d8bbd6c87f9c6d28bf2214d76f30a1b6@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:11 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:11 -0000

From ghc-devs at haskell.org Sat Oct 5 15:55:20 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 15:55:20 -0000 Subject: [GHC] #3658: Dynamically link GHCi (and use system linker) on

#2725: Remove Hack in compiler/nativeGen/MachCodeGen.hs -------------------------------------+------------------------------------ Reporter: clemens | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler (NCG) | Version: 6.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * cc: simonmar (added) * owner: clemens => thoughtpolice -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/2725#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler platforms that support it In-Reply-To: <047.129d39e2608fc274aa7ba90c094c6a82@haskell.org> References: <047.129d39e2608fc274aa7ba90c094c6a82@haskell.org> Message-ID: <062.036aa34160c3fd15224c26c55b8b6e12@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:11 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:11 -0000 #3658: Dynamically link GHCi (and use system linker) on platforms that support it -------------------------------------------------+------------------------- Reporter: simonmar | Owner: Type: task | thoughtpolice Priority: high | Status: new Component: GHCi | Milestone: 7.8.1 Resolution: | Version: Operating System: Unknown/Multiple | 6.10.4 Type of failure: None/Unknown | Keywords: Test Case: | dynamic link Blocking: 781, 1883, 2283, 3242, 3333, | Architecture: 3372, 3654, 4244, 5062, 5197, 6107, 7056, | Unknown/Multiple 7072, 7097, 7103, 7134, 7316, 7329, 7389, | Difficulty: 7475, 7687 | Unknown | Blocked By: 5987 | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * cc: hvr (added) * owner: => thoughtpolice -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/3658#comment:44 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 15:55:32 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 15:55:32 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.6b3fa0e498d2fbd0125e374bd90f686a@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:11 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:11 -0000

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------ Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 5877 -------------------------------------+------------------------------------ Changes (by thoughtpolice): * owner: => thoughtpolice -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/5218#comment:23 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 15:55:46 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 15:55:46 -0000 Subject: [GHC] #8366: haskeline Posix backend needs #include on Solaris In-Reply-To: <049.e865036198c31803d8a20d77075b82a9@haskell.org> References: <049.e865036198c31803d8a20d77075b82a9@haskell.org> Message-ID: <064.227b42b311f8ff2adb7e8099533d00a1@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:12 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:12 -0000

#8366: haskeline Posix backend needs #include on Solaris -------------------------------------+------------------------------------- Reporter: oddsignals | Owner: thoughtpolice Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: libraries | Version: 7.7 (other) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Solaris | Difficulty: Easy (less than 1 Type of failure: Building GHC | hour) failed | Blocked By: Test Case: | Related Tickets: 8361 Blocking: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * owner: => thoughtpolice -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8366#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 15:56:11 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 15:56:11 -0000 Subject: [GHC] #8228: GHC built under Windows does not generate dyn_hi files In-Reply-To: <045.75cbd05b617b871cecfcf573b0b5b3b2@haskell.org> References: <045.75cbd05b617b871cecfcf573b0b5b3b2@haskell.org> Message-ID: <060.308de2fbebb7bc2dca219a5d064716ef@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:12 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:12 -0000

#8228: GHC built under Windows does not generate dyn_hi files --------------------------------------------+------------------------------ Reporter: ezyang | Owner: Type: bug | thoughtpolice Priority: high | Status: new Component: Compiler | Milestone: 7.8.1 Resolution: | Version: 7.7 Operating System: Windows | Keywords: Type of failure: GHC doesn't work at all | Architecture: Test Case: cabal01 | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #7134 --------------------------------------------+------------------------------ Changes (by thoughtpolice): * owner: => thoughtpolice -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8228#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 15:56:23 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 15:56:23 -0000 Subject: [GHC] #7712: "make install" fails on Windows In-Reply-To: <047.064622a4292b316ea2066ece45649169@haskell.org> References: <047.064622a4292b316ea2066ece45649169@haskell.org> Message-ID: <062.d9e2e85338ec4a13550700887232fc4c@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:12 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:12 -0000

#7712: "make install" fails on Windows ------------------------------------------+-------------------------------- Reporter: dpratt71 | Owner: Type: bug | thoughtpolice Priority: high | Status: new Component: Build System | Milestone: 7.8.1 Resolution: | Version: 7.7 Operating System: Windows | Keywords: Type of failure: Installing GHC failed | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Changes (by thoughtpolice): * owner: => thoughtpolice -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7712#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 15:57:39 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 15:57:39 -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.6080f863d1414d5f35ba9fc67b758f47@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:12 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:12 -0000

#7152: Add flag to configure that skips overwriting of symlinks on install -------------------------------------+------------------------------------ Reporter: tibbe | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Build System | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * owner: => thoughtpolice Comment: I'll look into this for 7.8.1. I agree we should maybe have some `gcc_select` style thing, but I don't quite know how these works or the details of Debian's approach, so I may just do the simple thing first and come back to that. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7152#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 15:57:56 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 15:57:56 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.ece3af19657f72f0e6daf89e046b9d90@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:12 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:12 -0000

From ghc-devs at haskell.org Sat Oct 5 16:11:58 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 16:11:58 -0000 Subject: [GHC] #3658: Dynamically link GHCi (and use system linker) on

#8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | thoughtpolice Priority: highest | Status: patch Component: Build System | Milestone: 7.8.1 Resolution: | Version: 7.7 Operating System: MacOS X | Keywords: Type of failure: GHC doesn't work at all | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by AndreasVoellmy): * cc: andreas.voellmy@? (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8266#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler platforms that support it In-Reply-To: <047.129d39e2608fc274aa7ba90c094c6a82@haskell.org> References: <047.129d39e2608fc274aa7ba90c094c6a82@haskell.org> Message-ID: <062.7ed5317bac0e24b7da18ff80730b736b@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:12 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:12 -0000 #3658: Dynamically link GHCi (and use system linker) on platforms that support it -------------------------------------------------+------------------------- Reporter: simonmar | Owner: Type: task | thoughtpolice Priority: high | Status: new Component: GHCi | Milestone: 7.8.1 Resolution: | Version: Operating System: Unknown/Multiple | 6.10.4 Type of failure: None/Unknown | Keywords: Test Case: | dynamic link Blocking: 781, 1883, 2283, 3242, 3333, | Architecture: 3372, 3654, 4244, 5062, 5197, 6107, 7056, | Unknown/Multiple 7072, 7097, 7103, 7134, 7316, 7329, 7389, | Difficulty: 7475, 7687 | Unknown | Blocked By: 5987 | Related Tickets: -------------------------------------------------+------------------------- Changes (by AndreasVoellmy): * cc: andreas.voellmy@? (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/3658#comment:45 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 16:30:21 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 16:30:21 -0000 Subject: [GHC] #8395: Various testsuite fixes for cross-compilation/i386/etc. In-Reply-To: <047.7fc31e71e82f9b3201d752e81a2124df@haskell.org> References: <047.7fc31e71e82f9b3201d752e81a2124df@haskell.org> Message-ID: <062.8fb07de2b565d1a379121c815aaeb105@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:12 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:12 -0000

#8395: Various testsuite fixes for cross-compilation/i386/etc. ---------------------------------+--------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+--------------------------- Comment (by Austin Seipp ): In [changeset:5fcdb2a6059617cb2ffd53c4882e1b16fb6a8037/base]: {{{ #!CommitTicketReference repository="base" revision="5fcdb2a6059617cb2ffd53c4882e1b16fb6a8037" Port ThreadDelay001 to the "time" library ... as "old-time" isn't built when cross-compiling. Issue #8395. Signed-off-by: Austin Seipp <aseipp at pobox.com> }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8395#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 16:32:41 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 16:32:41 -0000 Subject: [GHC] #8414: ghc-pkg prevents dynamic library only packages Message-ID: <053.c57fa11cf8cece16048f38d65161c630@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:12 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:12 -0000

#8414: ghc-pkg prevents dynamic library only packages ------------------------------------+------------------------------------- Reporter: AndreasVoellmy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- GHC supports compiling Haskell libraries as dynamic libraries and building executables against dynamic libraries. GHCi seems to support loading modules from dynamic libraries, too. So it would seem that it should be possible to have packages that only include dynamic libraries, omitting the .a and .o files typically generated. cabal-install allows building dynamic libraries only, for example with the command "cabal install --disable-library-vanilla --enable-shared --disable-library-profiling". However, ghc-pkg register refuses to install the package without the .a files present. This seems to be a bug with ghc-pkg. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8414 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 16:34:58 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 16:34:58 -0000 Subject: [GHC] #8414: ghc-pkg prevents dynamic library only packages In-Reply-To: <053.c57fa11cf8cece16048f38d65161c630@haskell.org> References: <053.c57fa11cf8cece16048f38d65161c630@haskell.org> Message-ID: <068.bb63b13c373757f7cf0e68cd9774f92b@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:12 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:12 -0000

#8414: ghc-pkg prevents dynamic library only packages -------------------------------------+------------------------------------ Reporter: AndreasVoellmy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by AndreasVoellmy): I can provide a patch to ghc-pkg to change how it validates packages. However, before I do this, I would like someone to verify that a dynamic- library only package is reasonable and should be allowed. Things seem to work correctly for me if I allow it, but maybe I just got lucky on my platform. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8414#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 17:07:04 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 17:07:04 -0000 Subject: [GHC] #8413: testsuite: Allow to skip performance tests In-Reply-To: <046.054ac5c3ea1b0378aebbab7cc9439b5d@haskell.org> References: <046.054ac5c3ea1b0378aebbab7cc9439b5d@haskell.org> Message-ID: <061.cc3343738804541376f9e186de4b87de@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:12 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:12 -0000

#8413: testsuite: Allow to skip performance tests -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: feature request | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:7d29fbf373befbc0ee60dff01f6a9cabee047862/testsuite]: {{{ #!CommitTicketReference repository="testsuite" revision="7d29fbf373befbc0ee60dff01f6a9cabee047862" Flag to test suite: SKIP_PERF_TESTS More often than not the output of the performance tests is in the way, rather than helping. This allows the use of `make SKIP_PERF_TESTS=YES` to skip these tests. Fixes #8413 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8413#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 17:08:00 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 17:08:00 -0000 Subject: [GHC] #8413: testsuite: Allow to skip performance tests In-Reply-To: <046.054ac5c3ea1b0378aebbab7cc9439b5d@haskell.org> References: <046.054ac5c3ea1b0378aebbab7cc9439b5d@haskell.org> Message-ID: <061.2c4cebcabfaf33fbc42741796e025b57@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:12 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:12 -0000

#8413: testsuite: Allow to skip performance tests -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: feature request | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * status: patch => closed * resolution: => fixed Comment: After encouragement on IRC, pushed. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8413#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 17:10:32 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 17:10:32 -0000 Subject: [GHC] #4128: Can't capture classes inside a template haskell type quotation In-Reply-To: <044.6e31641c0a0ac08a9cd677b3a05583dc@haskell.org> References: <044.6e31641c0a0ac08a9cd677b3a05583dc@haskell.org> Message-ID: <059.d0744638517f4557adacfa38a2a13748@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:13 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:13 -0000

#4128: Can't capture classes inside a template haskell type quotation -------------------------------------+--------------------------------- Reporter: lilac | Owner: Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Template Haskell | Version: 6.12.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Test Case: | Blocked By: 4230 Blocking: | -------------------------------------+--------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:e595c81ee0951f17d34b918123dfa7711710fe89/testsuite]: {{{ #!CommitTicketReference repository="testsuite" revision="e595c81ee0951f17d34b918123dfa7711710fe89" Add tests for new TH #4124, #4128, #4170, #4364, #6062 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/4128#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 17:10:32 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 17:10:32 -0000 Subject: [GHC] #4364: Template Haskell: Cycle in type synonym declarations In-Reply-To: <044.c71969434042c7b99c58cb2c57d8a244@haskell.org> References: <044.c71969434042c7b99c58cb2c57d8a244@haskell.org> Message-ID: <059.4fd3141b6044ef8836ae8a565bea0949@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:13 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:13 -0000

#4364: Template Haskell: Cycle in type synonym declarations --------------------------------------------+------------------------------ Reporter: igloo | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Krzysztof Gogolewski ): In [changeset:e595c81ee0951f17d34b918123dfa7711710fe89/testsuite]: {{{ #!CommitTicketReference repository="testsuite" revision="e595c81ee0951f17d34b918123dfa7711710fe89" Add tests for new TH #4124, #4128, #4170, #4364, #6062 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/4364#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 17:10:33 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 17:10:33 -0000 Subject: [GHC] #4170: Invalid "duplicate instance" error In-Reply-To: <047.48b32ecd056200283f1bc42e9e956e84@haskell.org> References: <047.48b32ecd056200283f1bc42e9e956e84@haskell.org> Message-ID: <062.61df589da398a47650a438023e8896b2@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:13 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:13 -0000

From ghc-devs at haskell.org Sat Oct 5 17:10:36 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 17:10:36 -0000 Subject: [GHC] #4124: GHC rejects instance quotations with splices in

#4170: Invalid "duplicate instance" error -------------------------------------+--------------------------------- Reporter: verdelyi | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Template Haskell | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Test Case: | Blocked By: 4230 Blocking: | -------------------------------------+--------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:e595c81ee0951f17d34b918123dfa7711710fe89/testsuite]: {{{ #!CommitTicketReference repository="testsuite" revision="e595c81ee0951f17d34b918123dfa7711710fe89" Add tests for new TH #4124, #4128, #4170, #4364, #6062 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/4170#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler the instance head In-Reply-To: <044.47f82777009a60691ba558faa9c8d2f1@haskell.org> References: <044.47f82777009a60691ba558faa9c8d2f1@haskell.org> Message-ID: <059.828d72100221ec824839c04bfcfe83a5@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:13 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:13 -0000 #4124: GHC rejects instance quotations with splices in the instance head ----------------------------------------------+---------------------------- Reporter: lilac | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Template Haskell | Version: 6.12.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Blocking: | Blocked By: 4230 ----------------------------------------------+---------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:e595c81ee0951f17d34b918123dfa7711710fe89/testsuite]: {{{ #!CommitTicketReference repository="testsuite" revision="e595c81ee0951f17d34b918123dfa7711710fe89" Add tests for new TH #4124, #4128, #4170, #4364, #6062 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/4124#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 17:10:36 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 17:10:36 -0000 Subject: [GHC] #6062: TH treats non-functions in function position inconsistently In-Reply-To: <048.e175d5ec6fb0b5779878be3157fd91ca@haskell.org> References: <048.e175d5ec6fb0b5779878be3157fd91ca@haskell.org> Message-ID: <063.8ef7f4fc4d5a1d78b721435762348e30@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:13 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:13 -0000

#6062: TH treats non-functions in function position inconsistently -------------------------------------+------------------------------------ Reporter: heisenbug | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Krzysztof Gogolewski ): In [changeset:e595c81ee0951f17d34b918123dfa7711710fe89/testsuite]: {{{ #!CommitTicketReference repository="testsuite" revision="e595c81ee0951f17d34b918123dfa7711710fe89" Add tests for new TH #4124, #4128, #4170, #4364, #6062 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/6062#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 17:14:12 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 17:14:12 -0000 Subject: [GHC] #4128: Can't capture classes inside a template haskell type quotation In-Reply-To: <044.6e31641c0a0ac08a9cd677b3a05583dc@haskell.org> References: <044.6e31641c0a0ac08a9cd677b3a05583dc@haskell.org> Message-ID: <059.bc74bacf54e9aeaef7930edfbc604876@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:13 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:13 -0000

From ghc-devs at haskell.org Sat Oct 5 17:16:56 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 17:16:56 -0000 Subject: [GHC] #4124: GHC rejects instance quotations with splices in

#4128: Can't capture classes inside a template haskell type quotation -------------------------------------+------------------------------------ Reporter: lilac | Owner: Type: feature request | Status: closed Priority: low | Milestone: 7.6.2 Component: Template Haskell | Version: 6.12.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: th/T4128 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by monoidal): * status: new => closed * difficulty: => Unknown * resolution: => fixed * testcase: => th/T4128 * blockedby: 4230 => Comment: This test was already working as of GHC 7.6; I think this was fixed by addition of -XConstraintKinds. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/4128#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler the instance head In-Reply-To: <044.47f82777009a60691ba558faa9c8d2f1@haskell.org> References: <044.47f82777009a60691ba558faa9c8d2f1@haskell.org> Message-ID: <059.f048affd635764d026a1eb0858e3871b@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:13 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:13 -0000 #4124: GHC rejects instance quotations with splices in the instance head ----------------------------------------------+---------------------------- Reporter: lilac | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.6.2 Component: Template Haskell | Version: 6.12.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: th/4124 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by monoidal): * status: new => closed * difficulty: => Unknown * resolution: => fixed * testcase: => th/4124 * blockedby: 4230 => Comment: This is now fixed thanks to new TH. BTW for older GHC you could work around it by enabling -XFlexibleInstances (as the error suggests), but that was unneccessary and is now not needed. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/4124#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 17:19:07 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 17:19:07 -0000 Subject: [GHC] #4170: Invalid "duplicate instance" error In-Reply-To: <047.48b32ecd056200283f1bc42e9e956e84@haskell.org> References: <047.48b32ecd056200283f1bc42e9e956e84@haskell.org> Message-ID: <062.ae8334457488b01e74e99286163988c7@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:13 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:13 -0000

#4170: Invalid "duplicate instance" error -------------------------------------+------------------------------------ Reporter: verdelyi | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.6.2 Component: Template Haskell | Version: 6.12.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: th/T4170 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by monoidal): * status: new => closed * difficulty: => Unknown * resolution: => fixed * testcase: => th/T4170 * blockedby: 4230 => Comment: This is now fixed thanks to new TH. Woo hoo! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/4170#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 17:22:01 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 17:22:01 -0000 Subject: [GHC] #6062: TH treats non-functions in function position inconsistently In-Reply-To: <048.e175d5ec6fb0b5779878be3157fd91ca@haskell.org> References: <048.e175d5ec6fb0b5779878be3157fd91ca@haskell.org> Message-ID: <063.f97f87a0f63797bbfdad147301fd4bf1@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:14 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:14 -0000

#6062: TH treats non-functions in function position inconsistently -------------------------------------+------------------------------------ Reporter: heisenbug | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.5 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: th/T6062 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by monoidal): * status: new => closed * testcase: => th/T6062 * resolution: => fixed Comment: This is now fixed thanks to new TH. Woo hoo! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/6062#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 17:23:23 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 17:23:23 -0000 Subject: [GHC] #4364: Template Haskell: Cycle in type synonym declarations In-Reply-To: <044.c71969434042c7b99c58cb2c57d8a244@haskell.org> References: <044.c71969434042c7b99c58cb2c57d8a244@haskell.org> Message-ID: <059.714692f3637932a263f7bbe78d0148fe@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:14 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:14 -0000

#4364: Template Haskell: Cycle in type synonym declarations --------------------------------------------+------------------------------ Reporter: igloo | Owner: simonpj Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: th/T4364 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by monoidal): * status: new => closed * testcase: => th/T4364 * resolution: => fixed Comment: This is now fixed thanks to new TH. Woo hoo! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/4364#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 17:44:19 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 17:44:19 -0000 Subject: [GHC] #8276: Building Haddock documentation panics with perf build on x86_64 Linux In-Reply-To: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> References: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> Message-ID: <063.e3d2e5173ca62dba125d77ec94aaa5d8@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:14 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:14 -0000

#8276: Building Haddock documentation panics with perf build on x86_64 Linux ---------------------------------------+---------------------------------- Reporter: jstolarek | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Documentation | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by SimonHengel): Here is some (very simplified!) code from Doctest. In Haddock we have something similar. {{{ parse :: [String] -> IO [TypecheckedModule] parse args = bracket saveStaticFlagGlobals restoreStaticFlagGlobals $ \_ -> do args_ <- fst <$> parseStaticFlags (map noLoc args) runGhc (Just libdir) $ do (dynflags, files, _) <- getSessionDynFlags >>= (`parseDynamicFlags` args_) _ <- setSessionDynFlags dynflags mapM (`guessTarget` Nothing) (map unLoc files) >>= setTargets mods <- depanal [] False let sortedMods = flattenSCCs (topSortModuleGraph False mods Nothing) mapM (parseModule >=> typecheckModule >=> loadModule) sortedMods }}} (both Doctest and Haddock accept arbitrary GHC flags) If we can safely ignore static flags altogether, and change this to {{{ parse :: [String] -> IO [TypecheckedModule] parse args = runGhc (Just libdir) $ do (dynflags, files, _) <- getSessionDynFlags >>= (`parseDynamicFlags` map noLoc args) _ <- setSessionDynFlags dynflags mapM (`guessTarget` Nothing) (map unLoc files) >>= setTargets mods <- depanal [] False let sortedMods = flattenSCCs (topSortModuleGraph False mods Nothing) mapM (parseModule >=> typecheckModule >=> loadModule) sortedMods }}} then I have no need for {{{saveStaticFlagGlobals}}}/{{{restoreStaticFlagGlobals}}} anymore. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8276#comment:29 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 17:55:06 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 17:55:06 -0000 Subject: [GHC] #8276: Building Haddock documentation panics with perf build on x86_64 Linux In-Reply-To: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> References: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> Message-ID: <063.2368799b2fa526d1c723a11d7fb94239@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:14 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:14 -0000

#8276: Building Haddock documentation panics with perf build on x86_64 Linux ---------------------------------------+---------------------------------- Reporter: jstolarek | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Documentation | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by SimonHengel): Say, I would like to change Haddock like so: https://github.com/sol/haddock/commit/b03718b80f0366c1e495f52d9468019360a5cc... Are we sure, that e.g. `cabal-install` never passes any static flags to Haddock? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8276#comment:30 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 18:09:21 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 18:09:21 -0000 Subject: [GHC] #8275: Loopification breaks profiling In-Reply-To: <048.63a98da772d0fcd943c3debc22ba0a20@haskell.org> References: <048.63a98da772d0fcd943c3debc22ba0a20@haskell.org> Message-ID: <063.0a7c9e9d552f821507469271def8a0ff@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:14 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:14 -0000

#8275: Loopification breaks profiling ----------------------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Profiling | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: 8298 | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by jstolarek): * milestone: 7.10.1 => 7.8.1 Comment: I'm setting this to milestone 7.8.1 - we certainly don't want that breakage released. I will be fairly busy for the next 2-3 weeks, but I should have time in November to look into this. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8275#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 18:20:44 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 18:20:44 -0000 Subject: [GHC] #8322: Report all missing module, not just the first or last In-Reply-To: <046.b88d1a6a055419055d0d7b0e1ef0a4fe@haskell.org> References: <046.b88d1a6a055419055d0d7b0e1ef0a4fe@haskell.org> Message-ID: <061.c12a83d7f948e1e4c2d878c7da41ab4b@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:14 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:14 -0000

#8322: Report all missing module, not just the first or last -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * status: new => patch Comment: I did a round of self-code-review and made the code a bit nicer. I believe this can be merged now. Can someone review and me the green light? I?ll then push and push the test suite accordingly (`tcfail082` needs updating). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8322#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 18:23:38 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 18:23:38 -0000 Subject: [GHC] #8411: TypeSynonymInstances with partial type In-Reply-To: <042.08643ec9c49892b1ffcde20daa6f8b76@haskell.org> References: <042.08643ec9c49892b1ffcde20daa6f8b76@haskell.org> Message-ID: <057.bed910421a7ad26128d6d9aa36dce899@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:14 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:14 -0000

#8411: TypeSynonymInstances with partial type ----------------------------------------------+---------------------------- Reporter: wvv | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by monoidal): * status: new => closed * resolution: => invalid Comment: Unfortunately, this is by design. Partial application of type synonyms is highly nontrivial; if done, it would require a large upheaval of type inference, and add a lot of complexity. For example, how GHC could know whether given `return :: a -> (a,a)`, is `Monad ((,) a)` or `Monad (RTuple a)` required? The situation gets much more complicated with larger synonyms, and things get ugly. I suggest to ask this question on haskell- cafe or IRC and leave two links found by a google search: #785, http://stackoverflow.com/questions/4922560/. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8411#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 19:16:49 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 19:16:49 -0000 Subject: [GHC] #8406: Invalid object in isRetainer() or Segfault In-Reply-To: <047.cda95cb1752355077595406288b06592@haskell.org> References: <047.cda95cb1752355077595406288b06592@haskell.org> Message-ID: <062.b258cc1914cdeeed993332c03971eb65@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:14 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:14 -0000

#8406: Invalid object in isRetainer() or Segfault ----------------------------------+---------------------------------- Reporter: crockeea | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by simonmar): * status: new => infoneeded Comment: We had a similar problem a while back - #5909, but that was fixed in 7.6.2. Are you sure you're using 7.6.3? If so, we'll need some repro instructions. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8406#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 20:12:54 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 20:12:54 -0000 Subject: [GHC] #8281: The impossible happened: primRepToFFIType In-Reply-To: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> References: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> Message-ID: <059.03943b8accf247ddf9a69c3656fd2270@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:15 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:15 -0000

#8281: The impossible happened: primRepToFFIType ---------------------------------------+----------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by simonmar): We used to use `UnliftedFFITypes` quite a lot in the IO library in the base package, but I just looked and we use it very little now (only for `ThreadId#`). It does have a brief entry in the flags reference in the user's guide, but no proper documentation. As far as I recall we didn't intend it to be an advertised feature, so I'm not sure why it appears in the docs at all. So what's going wrong here is that we have a foreign call that takes a `ThreadId#`. The foreign call is marked unsafe, because (as you note, Simon) it couldn't work if it was safe. But GHCi only knows how to compile safe foreign calls - it ignores `unsafe` - so there's no way GHCi can compile this code such that it works. What I would like to do is get rid of `UnliftedFFITypes` and use `foreign import prim` instead. The example above is a good use for `foreign import prim`, and indeed we should change `GHC.Conc.Sync` to do it that way (where the example above was copy/pasted from, incidentally). But there are some places where `UnliftedFFITypes` is really useful, e.g.: {{{ foreign import ccall unsafe "memcpy" memcpy_freeze :: MutableByteArray# s -> MutableByteArray# s -> CSize -> IO (Ptr a) }}} from the `array` package. To do this with `foreign import prim` would mean another function call. So I think we have little choice here. - disallow passing boxed-but-unlifted types to safe foreign calls, except for arrays. This error would also trigger in GHCi for an unsafe call, because GHCi compiles unsafe calls as safe calls. Hence the above code would be rejected by GHCi, but accepted by GHC. - document `UnliftedFFITypes`, and explain the pitfalls: not fully supported by GHCi, and be careful passing arrays to `safe` calls (they must be pinned). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8281#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 20:47:07 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 20:47:07 -0000 Subject: [GHC] #8170: Remove _scc_ In-Reply-To: <047.7f6701e7774fc31251fca4a484c23de1@haskell.org> References: <047.7f6701e7774fc31251fca4a484c23de1@haskell.org> Message-ID: <062.a7622f941c7fef4c34c1cbc44a5f2986@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:15 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:15 -0000

#8170: Remove _scc_ -------------------------------------+------------------------------------ Reporter: monoidal | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Krzysztof Gogolewski ): In [changeset:3e0109b302bbd9f849d71cbc3efcc905d5271e4e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3e0109b302bbd9f849d71cbc3efcc905d5271e4e" Remove deprecated _scc_ (#8170) }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8170#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 20:47:23 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 20:47:23 -0000 Subject: [GHC] #8170: Remove _scc_ In-Reply-To: <047.7f6701e7774fc31251fca4a484c23de1@haskell.org> References: <047.7f6701e7774fc31251fca4a484c23de1@haskell.org> Message-ID: <062.e56ccb504b55cb314fc8286344ae8efd@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:15 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:15 -0000

#8170: Remove _scc_ -------------------------------------+------------------------------------ Reporter: monoidal | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Krzysztof Gogolewski ): In [changeset:d7b4529a141716c7f9c375d0a5b46349e5634e0b/testsuite]: {{{ #!CommitTicketReference repository="testsuite" revision="d7b4529a141716c7f9c375d0a5b46349e5634e0b" Change deprecated _scc_ to {-# SCC #-} (#8170) }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8170#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 20:52:48 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 20:52:48 -0000 Subject: [GHC] #8170: Remove _scc_ In-Reply-To: <047.7f6701e7774fc31251fca4a484c23de1@haskell.org> References: <047.7f6701e7774fc31251fca4a484c23de1@haskell.org> Message-ID: <062.5defd6a3c2a7f8b5a8800b1486818a88@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:15 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:15 -0000

#8170: Remove _scc_ -------------------------------------+------------------------------------ Reporter: monoidal | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Krzysztof Gogolewski ): In [changeset:b9d8bcdd929d664539843f96e56b50800f623891/nofib]: {{{ #!CommitTicketReference repository="nofib" revision="b9d8bcdd929d664539843f96e56b50800f623891" Remove deprecated _scc_ (#8170) }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8170#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 20:56:28 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 20:56:28 -0000 Subject: [GHC] #8170: Remove _scc_ In-Reply-To: <047.7f6701e7774fc31251fca4a484c23de1@haskell.org> References: <047.7f6701e7774fc31251fca4a484c23de1@haskell.org> Message-ID: <062.0f47da6b345b2143fab9f70252edbd64@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:15 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:15 -0000

#8170: Remove _scc_ -------------------------------------+------------------------------------ Reporter: monoidal | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by monoidal): * status: patch => closed * resolution: => fixed Comment: I've applied the changes, except for the megapatch to one happy-generated file which seemed pointless. (Austin consented to me finishing the ticket.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8170#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 5 23:56:31 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Oct 2013 23:56:31 -0000 Subject: [GHC] #8366: haskeline Posix backend needs #include on Solaris In-Reply-To: <049.e865036198c31803d8a20d77075b82a9@haskell.org> References: <049.e865036198c31803d8a20d77075b82a9@haskell.org> Message-ID: <064.f07df4e9861e11cf8b05ecd4a15557b6@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:15 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:15 -0000

#8366: haskeline Posix backend needs #include on Solaris -------------------------------------+------------------------------------- Reporter: oddsignals | Owner: thoughtpolice Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: libraries | Version: 7.7 (other) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Solaris | Difficulty: Easy (less than 1 Type of failure: Building GHC | hour) failed | Blocked By: Test Case: | Related Tickets: 8361 Blocking: | -------------------------------------+------------------------------------- Comment (by oddsignals): I've attached a patch for the segfaulting GHCi Solaris issue as well, as discussed on IRC. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8366#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sun Oct 6 00:26:53 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Oct 2013 00:26:53 -0000 Subject: [GHC] #8276: Building Haddock documentation panics with perf build on x86_64 Linux In-Reply-To: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> References: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> Message-ID: <063.d40f223a64f463e7f2d114ec293a20b0@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:15 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:15 -0000

#8276: Building Haddock documentation panics with perf build on x86_64 Linux ---------------------------------------+---------------------------------- Reporter: jstolarek | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Documentation | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by JohnWiegley): * cc: johnw@? (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8276#comment:31 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sun Oct 6 01:08:48 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Oct 2013 01:08:48 -0000 Subject: [GHC] #4135: Can't Quote Instance Associated Types in Template Haskell In-Reply-To: <053.188af2ea03c2f430124b5ce57806b9f1@haskell.org> References: <053.188af2ea03c2f430124b5ce57806b9f1@haskell.org> Message-ID: <068.e8a7ac87a49391bfc4ae89d150a64150@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:16 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:16 -0000

#4135: Can't Quote Instance Associated Types in Template Haskell ----------------------------------------------+---------------------------- Reporter: Ashley Yakeley | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Template Haskell | Version: 6.12.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects valid program | (amd64) Test Case: th/T4135 | Difficulty: Unknown Blocking: | Blocked By: 4230 | Related Tickets: ----------------------------------------------+---------------------------- Changes (by shelarcy): * testcase: => th/T4135 * difficulty: => Unknown Comment: Why is this still open? Above commit log says fixes this, and test case is already added by ccd14ae24656440e4746a888d070b8922871408a/testsuite. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/4135#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sun Oct 6 02:36:23 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Oct 2013 02:36:23 -0000 Subject: [GHC] #8406: Invalid object in isRetainer() or Segfault In-Reply-To: <047.cda95cb1752355077595406288b06592@haskell.org> References: <047.cda95cb1752355077595406288b06592@haskell.org> Message-ID: <062.a1dba7f5c6a0ae69faf4b1ba52ff9481@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:16 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:16 -0000

#8406: Invalid object in isRetainer() or Segfault ----------------------------------+---------------------------------- Reporter: crockeea | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by crockeea): I had the problem in 7.6.2, then specifically upgraded to 7.6.3 in the hopes it would be fixed. No dice. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8406#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sun Oct 6 03:32:51 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Oct 2013 03:32:51 -0000 Subject: [GHC] #8413: testsuite: Allow to skip performance tests In-Reply-To: <046.054ac5c3ea1b0378aebbab7cc9439b5d@haskell.org> References: <046.054ac5c3ea1b0378aebbab7cc9439b5d@haskell.org> Message-ID: <061.433a87c1bcd998f52b96bde2a1fdf8f7@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:16 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:16 -0000

#8413: testsuite: Allow to skip performance tests -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: feature request | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): Should this perhaps be added to [wiki:Building/RunningTests/Running the testsuite instructions page]? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8413#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sun Oct 6 04:21:54 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Oct 2013 04:21:54 -0000 Subject: [GHC] #2289: Needless reboxing of values when returning from a tight loop In-Reply-To: <043.32b2235b0e9fe1aba0c28a0cd28686b3@haskell.org> References: <043.32b2235b0e9fe1aba0c28a0cd28686b3@haskell.org> Message-ID: <058.57d95626fba80331019bada0df52f128@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:16 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:16 -0000

#2289: Needless reboxing of values when returning from a tight loop -------------------------------------+------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.8.2 Resolution: | Keywords: boxing, loops, Operating System: Unknown/Multiple | performance Type of failure: Runtime | Architecture: Unknown/Multiple performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #2387,#1600 -------------------------------------+------------------------------------- Comment (by carter): whats the status of this codegen issue? Was this one of the problems that were supposed to be addressed with loopification? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/2289#comment:34 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sun Oct 6 09:26:35 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Oct 2013 09:26:35 -0000 Subject: [GHC] #2289: Needless reboxing of values when returning from a tight loop In-Reply-To: <043.32b2235b0e9fe1aba0c28a0cd28686b3@haskell.org> References: <043.32b2235b0e9fe1aba0c28a0cd28686b3@haskell.org> Message-ID: <058.6e1c82cc6cd438225877349d19381870@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:16 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:16 -0000

#2289: Needless reboxing of values when returning from a tight loop -------------------------------------+------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.8.2 Resolution: | Keywords: boxing, loops, Operating System: Unknown/Multiple | performance Type of failure: Runtime | Architecture: Unknown/Multiple performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #2387,#1600 -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:34 carter]:

Was this one of the problems that were supposed to be addressed with loopification? No. I was planning to look into this bug during my internship, but in the end I didn't have enough time.

-- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/2289#comment:35 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sun Oct 6 10:12:04 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Oct 2013 10:12:04 -0000 Subject: [GHC] #4135: Can't Quote Instance Associated Types in Template Haskell In-Reply-To: <053.188af2ea03c2f430124b5ce57806b9f1@haskell.org> References: <053.188af2ea03c2f430124b5ce57806b9f1@haskell.org> Message-ID: <068.202a5ddbe72f31f500fd5ab0ef656be4@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:16 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:16 -0000

#4135: Can't Quote Instance Associated Types in Template Haskell ----------------------------------------------+---------------------------- Reporter: Ashley Yakeley | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Template Haskell | Version: 6.12.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects valid program | (amd64) Test Case: th/T4135 | Difficulty: Unknown Blocking: | Blocked By: 4230 | Related Tickets: ----------------------------------------------+---------------------------- Comment (by monoidal): shelarcy: The program from comment:2 still does not compile in HEAD. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/4135#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sun Oct 6 10:55:23 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Oct 2013 10:55:23 -0000 Subject: [GHC] #8413: testsuite: Allow to skip performance tests In-Reply-To: <046.054ac5c3ea1b0378aebbab7cc9439b5d@haskell.org> References: <046.054ac5c3ea1b0378aebbab7cc9439b5d@haskell.org> Message-ID: <061.066c37d4c2ebc1390cb5634bba83d0b8@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:16 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:16 -0000

#8413: testsuite: Allow to skip performance tests -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: feature request | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): It?s a rather special feature, so I figured it is sufficient do document it in [[Building/RunningTests/Settings]]. If you disagree: It?s a wiki :-) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8413#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sun Oct 6 15:38:54 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Oct 2013 15:38:54 -0000 Subject: [GHC] #4135: Can't Quote Instance Associated Types in Template Haskell In-Reply-To: <053.188af2ea03c2f430124b5ce57806b9f1@haskell.org> References: <053.188af2ea03c2f430124b5ce57806b9f1@haskell.org> Message-ID: <068.7ecdf9505445197958d9bae06d335515@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:16 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:16 -0000

#4135: Can't Quote Instance Associated Types in Template Haskell ----------------------------------------------+---------------------------- Reporter: Ashley Yakeley | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Template Haskell | Version: 6.12.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects valid program | (amd64) Test Case: th/T4135 | Difficulty: Unknown Blocking: | Blocked By: 4230 | Related Tickets: ----------------------------------------------+---------------------------- Comment (by shelarcy): Replying to [comment:15 monoidal]: I see. I missed that. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/4135#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sun Oct 6 21:12:11 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Oct 2013 21:12:11 -0000 Subject: [GHC] #7794: GHCi "Prelude.undefined" exceptions on ARM; ByteCodeItbls.mkJumpToAddr unimplemented In-Reply-To: <047.cfb9dd0cccf053eb65d46aac8dec8ad0@haskell.org> References: <047.cfb9dd0cccf053eb65d46aac8dec8ad0@haskell.org> Message-ID: <062.0044c9277b45718bce607cf3436588b4@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:17 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:17 -0000

#7794: GHCi "Prelude.undefined" exceptions on ARM; ByteCodeItbls.mkJumpToAddr unimplemented -------------------------------+--------------------------- Reporter: cjwatson | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+--------------------------- Changes (by nomeata): * cc: hvr (added) Comment: There is a related ticket/patch at #8380. Colin, what do you say to [ticket:8380#comment:4]? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7794#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sun Oct 6 21:30:51 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Oct 2013 21:30:51 -0000 Subject: [GHC] #7593: Unable to print exceptions of unicode identifiers In-Reply-To: <044.180348374c60284a01c4dfa59f341d42@haskell.org> References: <044.180348374c60284a01c4dfa59f341d42@haskell.org> Message-ID: <059.30fff78af6686a8e80eac35c1e266882@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:17 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:17 -0000

#7593: Unable to print exceptions of unicode identifiers -------------------------------------------------+------------------------- Reporter: dagit | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect warning at | Unknown/Multiple compile-time | Difficulty: Test Case: | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by nomeata): Just FTR: It works with 7.6.1 on Linux, so the `Windows` attribute seems to be correct. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7593#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sun Oct 6 21:37:40 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Oct 2013 21:37:40 -0000 Subject: [GHC] #7650: can't use combining characters in identifiers In-Reply-To: <044.4fb0377eab552e230ee53da0d70baa3c@haskell.org> References: <044.4fb0377eab552e230ee53da0d70baa3c@haskell.org> Message-ID: <059.c33c46f82219ac1b60e6ba078dd895c6@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:17 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:17 -0000

#7650: can't use combining characters in identifiers ---------------------------------+--------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+--------------------------- Comment (by nomeata): GHC already uses alex-3.1.0; that alone did not fix it. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7650#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sun Oct 6 21:40:18 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Oct 2013 21:40:18 -0000 Subject: [GHC] #7685: :script command does not resolve ~ In-Reply-To: <046.cb641c7d9e463a4d3ab2a24ca4b94786@haskell.org> References: <046.cb641c7d9e463a4d3ab2a24ca4b94786@haskell.org> Message-ID: <061.311465864a11159e22423020a799e559@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:17 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:17 -0000

#7685: :script command does not resolve ~ -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * cc: hvr (added) * status: new => patch Comment: Fix was easy; please merge from branch `WIP/T7685` or tell me to go ahead: http://git.haskell.org/ghc.git/commit/181975b01c1c84f22700e0e1ee64b9124b60cc... -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7685#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sun Oct 6 21:57:19 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Oct 2013 21:57:19 -0000 Subject: [GHC] #7374: rule not firing In-Reply-To: <044.acff8d27aac517b0ec7591b52176639d@haskell.org> References: <044.acff8d27aac517b0ec7591b52176639d@haskell.org> Message-ID: <059.77af829cbcae711e9a7ca8dc25e15b9d@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:17 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:17 -0000

#7374: rule not firing -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Looking at these many reports about rules not firing (e.g. #7398) due to other stuff happening earlier I wonder: Can?t we have a round of applying rules very early, before any inlining? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7374#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sun Oct 6 22:48:56 2013 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Oct 2013 22:48:56 -0000 Subject: [GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?) In-Reply-To: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> References: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> Message-ID: <062.ac032f08b2f34b76924fe115165db5fa@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:17 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:17 -0000

From ghc-devs at haskell.org Mon Oct 7 01:38:39 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 01:38:39 -0000 Subject: [GHC] #8134: ghc enters a loop while building 7.6.3 for

#7602: Threaded RTS performing badly on recent OS X (10.8?) -----------------------------------+---------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 7678 Blocking: | Related Tickets: -----------------------------------+---------------------------------- Comment (by ezyang): I must admit, I'm surprised that passing the thread-local state as a variable is not good performance-wise. At least within a function like evacuate, where everything ends up getting inlined into one giant function body, register pressure on x86_64 is low enough that I have seen (experimentally) that GCC is able to arrange for an extra parameter to not get spilled. Perhaps the situation is not so good across function call boundaries, but I don't see why it should necessarily be a problem. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7602#comment:29 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler powerpc64 platform. In-Reply-To: <043.0289be94f89f3f22e5a1a6cc61dcce1b@haskell.org> References: <043.0289be94f89f3f22e5a1a6cc61dcce1b@haskell.org> Message-ID: <058.784146785743a13a531b3a1bb45863b1@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:18 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:18 -0000 #8134: ghc enters a loop while building 7.6.3 for powerpc64 platform. -------------------------------------+----------------------------- Reporter: k0da | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.3 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+----------------------------- Comment (by juhpetersen): Replying to [comment:8 trommler]:

But we don't see the issue on PowerPC 32 bit, which is registerized and has a native code generator. PowerPC 64 is unregisterized.

Correct - nor on s390 which is also unregisterized. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8134#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Mon Oct 7 01:48:19 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 01:48:19 -0000 Subject: [GHC] #8297: Allow implicit parameters to take a default value In-Reply-To: <046.83de0442d66d57dde8079b4e8339312b@haskell.org> References: <046.83de0442d66d57dde8079b4e8339312b@haskell.org> Message-ID: <061.e91f3424f548367395cab4d5b59092ef@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:18 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:18 -0000

#8297: Allow implicit parameters to take a default value ----------------------------+---------------------------------------------- Reporter: schyler | Owner: Type: feature | Status: closed request | Milestone: _|_ Priority: low | Version: Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: invalid | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by schyler): Proved "impossible" on IRC. {{{ 12:40 PM <dolio> Ghoul_: By the way, I thought of an even more devious problem with your implicit proposal. :) 12:41 PM <dolio> Suppose I write 'sort' such that the comparison is implicit (instead writing both sort and sortBy). 12:42 PM <dolio> But, I say the default comparison is the one given by Ord. Now sort imposes a type class obligation iff you don't have an implicit argument binding in scope. }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8297#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Mon Oct 7 01:56:52 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 01:56:52 -0000 Subject: [GHC] #8131: T7571 with WAY=llvm fails, but not WAY=optllvm In-Reply-To: <052.22eb4f882263987206e929bacae5db28@haskell.org> References: <052.22eb4f882263987206e929bacae5db28@haskell.org> Message-ID: <067.f81cb7552cb816412f18fee7b0238118@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:18 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:18 -0000

#8131: T7571 with WAY=llvm fails, but not WAY=optllvm ----------------------------------------------+---------------------------- Reporter: thoughtpolice | Owner: rwbarton Type: bug | Status: patch Priority: high | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: llvm/should_compile/T8131 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by thoughtpolice): * status: new => patch -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8131#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Mon Oct 7 04:46:20 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 04:46:20 -0000 Subject: [GHC] #8402: throwTo segfaults under -prof -threaded -with-rtsopts=N2 In-Reply-To: <043.0ab089710edd4b363b63a9d75aa20e5f@haskell.org> References: <043.0ab089710edd4b363b63a9d75aa20e5f@haskell.org> Message-ID: <058.435a1a514fc0ce76e825c7afd4391996@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:18 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:18 -0000

#8402: throwTo segfaults under -prof -threaded -with-rtsopts=N2 ----------------------------------+---------------------------------- Reporter: akio | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Profiling | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by kazu-yamamoto): * cc: kazu@? (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8402#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Mon Oct 7 05:53:27 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 05:53:27 -0000 Subject: [GHC] #8402: throwTo segfaults under -prof -threaded -with-rtsopts=N2 In-Reply-To: <043.0ab089710edd4b363b63a9d75aa20e5f@haskell.org> References: <043.0ab089710edd4b363b63a9d75aa20e5f@haskell.org> Message-ID: <058.63842211ed62f96c6720943f21a03ec7@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:18 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:18 -0000

#8402: throwTo segfaults under -prof -threaded -with-rtsopts=N2 ----------------------------------+---------------------------------- Reporter: akio | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Profiling | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by kazu-yamamoto): I'm trying to profile my web server with GHC head (+RTS -Nx -p). Without ezyang's patch, it causes a segfault when I type C-c to stop the server. With GHC 7.6.3, C-c stops the server and generates a profile file. With ezyang's patch, this segfault disappeared. However, all counters are displayed 0: {{{ individual inherited COST CENTRE MODULE no. entries %time %alloc %time %alloc MAIN MAIN 347 0 100.0 100.0 100.0 100.0 CAF Main 693 0 0.0 0.0 0.0 0.0 CAF Server 692 0 0.0 0.0 0.0 0.0 CAF WaiApp 690 0 0.0 0.0 0.0 0.0 CAF Program.Mighty.Config 688 0 0.0 0.0 0.0 0.0 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8402#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Mon Oct 7 05:55:10 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 05:55:10 -0000 Subject: [GHC] #8402: throwTo segfaults under -prof -threaded -with-rtsopts=N2 In-Reply-To: <043.0ab089710edd4b363b63a9d75aa20e5f@haskell.org> References: <043.0ab089710edd4b363b63a9d75aa20e5f@haskell.org> Message-ID: <058.c5ee328acedaa20177ce32178f0fc14e@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:18 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:18 -0000

#8402: throwTo segfaults under -prof -threaded -with-rtsopts=N2 ----------------------------------+---------------------------------- Reporter: akio | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Profiling | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by kazu-yamamoto): This "0 report" is created even with -N1. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8402#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Mon Oct 7 07:32:13 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 07:32:13 -0000 Subject: [GHC] #8402: throwTo segfaults under -prof -threaded -with-rtsopts=N2 In-Reply-To: <043.0ab089710edd4b363b63a9d75aa20e5f@haskell.org> References: <043.0ab089710edd4b363b63a9d75aa20e5f@haskell.org> Message-ID: <058.b10c0c9e0ddcd8ffe4947d330a3e0033@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:18 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:18 -0000

#8402: throwTo segfaults under -prof -threaded -with-rtsopts=N2 ----------------------------------+---------------------------------- Reporter: akio | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Profiling | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by kazu-yamamoto): Never mind. I forgot to specify --ghc-options="-fprof-auto -fprof-cafs" to cabal. I can get a proper profiling file if I specify it. So, I hope that ezyang's patch will be merged quickly. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8402#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Mon Oct 7 08:46:03 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 08:46:03 -0000 Subject: [GHC] #8415: GHC bug using darcs on Kubuntu 13.04 Message-ID: <050.0cd78a7f5d73080db989012caf89186c@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:18 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:18 -0000

#8415: GHC bug using darcs on Kubuntu 13.04 ----------------------------------+------------------------------------- Reporter: JoeAquilina | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------------- I was trying to push a darcs patch when it failed with a GHC error. This is the text of the error message on the console: darcs: internal error: evacuate: strange closure type 536064 (GHC version 7.6.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) Not sure if this is exactly what is required when reporting a bug, I am very new to this and am unsure of the procedures involved regarding GHC bug reporting. Thanks in advance. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8415 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Mon Oct 7 09:32:09 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 09:32:09 -0000 Subject: [GHC] #8415: GHC bug using darcs on Kubuntu 13.04 In-Reply-To: <050.0cd78a7f5d73080db989012caf89186c@haskell.org> References: <050.0cd78a7f5d73080db989012caf89186c@haskell.org> Message-ID: <065.238833d13ccd7ebe87d768c2844c9ba6@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:19 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:19 -0000

#8415: GHC bug using darcs on Kubuntu 13.04 -------------------------------------+---------------------------------- Reporter: JoeAquilina | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by hvr): * cc: simonmar (added) * failure: None/Unknown => Runtime crash * component: Compiler => Runtime System * owner: => simonmar Old description:

I was trying to push a darcs patch when it failed with a GHC error. This is the text of the error message on the console:

darcs: internal error: evacuate: strange closure type 536064 (GHC version 7.6.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped)

Not sure if this is exactly what is required when reporting a bug, I am very new to this and am unsure of the procedures involved regarding GHC bug reporting.

Thanks in advance.

New description: I was trying to push a Darcs patch when it failed with a GHC error. This is the text of the error message on the console: {{{ darcs: internal error: evacuate: strange closure type 536064 (GHC version 7.6.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} Not sure if this is exactly what is required when reporting a bug, I am very new to this and am unsure of the procedures involved regarding GHC bug reporting. Thanks in advance. -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8415#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Mon Oct 7 10:49:08 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 10:49:08 -0000 Subject: [GHC] #7767: "internal error: evacuate: strange closure type 154886248" crash In-Reply-To: <047.0b39935f5cb7eca0e8f06868adf551de@haskell.org> References: <047.0b39935f5cb7eca0e8f06868adf551de@haskell.org> Message-ID: <062.fc34d71dc49ca3731c2c81dc3976f940@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:19 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:19 -0000

#7767: "internal error: evacuate: strange closure type 154886248" crash -----------------------------------+---------------------------------- Reporter: rodlogic | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Changes (by schyler): * cc: simonmar (added) * type: feature request => bug -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7767#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Mon Oct 7 12:22:10 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 12:22:10 -0000 Subject: [GHC] #7794: GHCi "Prelude.undefined" exceptions on ARM; ByteCodeItbls.mkJumpToAddr unimplemented In-Reply-To: <047.cfb9dd0cccf053eb65d46aac8dec8ad0@haskell.org> References: <047.cfb9dd0cccf053eb65d46aac8dec8ad0@haskell.org> Message-ID: <062.9088c3ce47a8c904cd4adc608657d5b7@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:19 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:19 -0000

#7794: GHCi "Prelude.undefined" exceptions on ARM; ByteCodeItbls.mkJumpToAddr unimplemented -------------------------------+--------------------------- Reporter: cjwatson | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+--------------------------- Comment (by cjwatson): Things have moved on quite a bit since I last checked, but that ticket does look essentially the same as this one. When I last looked, though, GHCi wasn't actually using the relevant part of libffi in the newExecConItbl path, and I still can't find anything that would do this. Am I missing something here or is bgamari? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7794#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Mon Oct 7 12:23:40 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 12:23:40 -0000 Subject: [GHC] #8380: Numerous testsuite failures on ARM due to missing mkJumpToAddr In-Reply-To: <046.6822dd2c7a2b1392cbd1b6deb902b274@haskell.org> References: <046.6822dd2c7a2b1392cbd1b6deb902b274@haskell.org> Message-ID: <061.dfb0b3ae8846610420914d3b884023f2@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:19 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:19 -0000

#8380: Numerous testsuite failures on ARM due to missing mkJumpToAddr -------------------------------------+--------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: patch Operating System: Unknown/Multiple | Architecture: arm Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+--------------------------- Comment (by cjwatson): The GHCi byte code generator doesn't actually appear to use libffi to generate trampolines, so I'm not sure how its cache-clearing code would take effect. Am I missing something? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8380#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Mon Oct 7 12:24:03 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 12:24:03 -0000 Subject: [GHC] #8380: Numerous testsuite failures on ARM due to missing mkJumpToAddr In-Reply-To: <046.6822dd2c7a2b1392cbd1b6deb902b274@haskell.org> References: <046.6822dd2c7a2b1392cbd1b6deb902b274@haskell.org> Message-ID: <061.fa307921ed74b8e5e7bf89260129500a@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:19 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:19 -0000

#8380: Numerous testsuite failures on ARM due to missing mkJumpToAddr -------------------------------------+--------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: patch Operating System: Unknown/Multiple | Architecture: arm Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+--------------------------- Changes (by cjwatson): * cc: cjwatson@? (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8380#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Mon Oct 7 15:03:22 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 15:03:22 -0000 Subject: [GHC] #8416: GHC.Generics needs more documentation Message-ID: <044.12e90915219726766b58c538fb55bf12@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:19 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:19 -0000

#8416: GHC.Generics needs more documentation -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Recently I tried to used `GHC.Generics` "in anger" for the first time, to fix some code in hashable that wasn't originally written by me. After a while I just gave up (and the generics support in hashable is now somewhat broken). The documentation for `GHC.Generics` is too incomprehensible for mere mortals. In particular, I find the documentation for `M1` and `K1` not very helpful. The documentation needs examples, more in-depth explanations of what each of the data types/constructors is used for, and finally an explanation of the up to 4 type parameters! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8416 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Mon Oct 7 15:10:27 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 15:10:27 -0000 Subject: [GHC] #8416: GHC.Generics needs more documentation In-Reply-To: <044.12e90915219726766b58c538fb55bf12@haskell.org> References: <044.12e90915219726766b58c538fb55bf12@haskell.org> Message-ID: <059.bb4af5db05991a1d8de9f4824ac0c75a@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:19 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:19 -0000

#8416: GHC.Generics needs more documentation --------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by refold): I think that this is fixed in HEAD: https://github.com/ghc/packages- base/commit/3b4ee00e3676c30814cd6ae68275cece0ba60b0d ? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8416#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Mon Oct 7 15:22:52 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 15:22:52 -0000 Subject: [GHC] #8416: GHC.Generics needs more documentation In-Reply-To: <044.12e90915219726766b58c538fb55bf12@haskell.org> References: <044.12e90915219726766b58c538fb55bf12@haskell.org> Message-ID: <059.5e5d105483aad7fd5cd0e434146a3908@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:19 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:19 -0000

#8416: GHC.Generics needs more documentation --------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries (other) | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by tibbe): * status: new => closed * resolution: => fixed -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8416#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Mon Oct 7 16:07:08 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 16:07:08 -0000 Subject: [GHC] #8416: GHC.Generics needs more documentation In-Reply-To: <044.12e90915219726766b58c538fb55bf12@haskell.org> References: <044.12e90915219726766b58c538fb55bf12@haskell.org> Message-ID: <059.404348b42b251ac4f4ec8089c6733e92@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:19 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:19 -0000

#8416: GHC.Generics needs more documentation --------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Documentation bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by hvr): * failure: None/Unknown => Documentation bug * milestone: => 7.8.1 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8416#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Mon Oct 7 16:10:27 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 16:10:27 -0000 Subject: [GHC] #3553: parallel gc suffers badly if one thread is descheduled In-Reply-To: <047.48e7cf5ad32bf05ce8bca6e11b9273f8@haskell.org> References: <047.48e7cf5ad32bf05ce8bca6e11b9273f8@haskell.org> Message-ID: <062.10eefa32882d95e384c5c44897f8e991@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:19 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:19 -0000

import Control.Parallel import Control.Parallel.Strategies (Strategy, withStrategy, rseq,

#3553: parallel gc suffers badly if one thread is descheduled -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.2 Component: Runtime System | Version: 6.10.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by parcs): * cc: simonmar (added) Comment: I noticed that if I change `nofib/parallel/ray` to do its work in a separate thread (see diff), that this "last core slowdown" completely vanishes. Can anybody explain this massive variance? {{{ #!diff diff --git a/parallel/ray/Main.lhs b/parallel/ray/Main.lhs index a1a72e6..bcd020f 100644 --- a/parallel/ray/Main.lhs +++ b/parallel/ray/Main.lhs @@ -5,10 +5,15 @@ Michaelson for SML, converted to (parallel) Haskell by Kevin Hammond! parBuffer)

import System.Environment +> import Control.Concurrent

main = do -> [detail] <- fmap (map read) getArgs -> putStr (top detail 10.0 7.0 6.0 sc) +> v <- newEmptyMVar +> forkIO $ do +> [detail] <- fmap (map read) getArgs +> putStr (top detail 10.0 7.0 6.0 sc) +> putMVar v () +> takeMVar v

type Coord = (Double,Double,Double)

}}} Before patch: {{{ parcs at wolfgang:~/ghc/nofib/parallel/ray$ perf stat ./ray 3000 +RTS -N > /dev/null Performance counter stats for './ray 3000 +RTS -N': 94255.765778 task-clock # 6.343 CPUs utilized 2,686,596 context-switches # 0.029 M/sec 6,592 CPU-migrations # 0.000 M/sec 2,243 page-faults # 0.000 M/sec 338,901,646,069 cycles # 3.596 GHz <not supported> stalled-cycles-frontend <not supported> stalled-cycles-backend 264,852,020,580 instructions # 0.78 insns per cycle 48,676,712,628 branches # 516.432 M/sec 1,114,612,869 branch-misses # 2.29% of all branches 14.859603166 seconds time elapsed }}} After patch: {{{ parcs at wolfgang:~/ghc/nofib/parallel/ray$ perf stat ./ray 3000 +RTS -N > /dev/null Performance counter stats for './ray 3000 +RTS -N': 65701.145514 task-clock # 7.919 CPUs utilized 41,217 context-switches # 0.001 M/sec 101 CPU-migrations # 0.000 M/sec 2,274 page-faults # 0.000 M/sec 242,921,371,383 cycles # 3.697 GHz <not supported> stalled-cycles-frontend <not supported> stalled-cycles-backend 216,526,115,297 instructions # 0.89 insns per cycle 39,079,392,369 branches # 594.805 M/sec 840,462,837 branch-misses # 2.15% of all branches 8.296947901 seconds time elapsed }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/3553#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Mon Oct 7 16:24:55 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 16:24:55 -0000 Subject: [GHC] #3553: parallel gc suffers badly if one thread is descheduled In-Reply-To: <047.48e7cf5ad32bf05ce8bca6e11b9273f8@haskell.org> References: <047.48e7cf5ad32bf05ce8bca6e11b9273f8@haskell.org> Message-ID: <062.69878390db2dddf21e17f4a1c48e0b15@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:20 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:20 -0000

#3553: parallel gc suffers badly if one thread is descheduled -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.2 Component: Runtime System | Version: 6.10.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe):

I noticed that if I change nofib/parallel/ray to do its work in a separate thread (see diff), that this "last core slowdown" completely vanishes. Can anybody explain this massive variance?

It could be because main runs in a bound thread. Why that makes a huge difference I'm not sure (more context switching?), but that's a likely cause. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/3553#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Mon Oct 7 16:31:21 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 16:31:21 -0000 Subject: [GHC] #8416: GHC.Generics needs more documentation In-Reply-To: <044.12e90915219726766b58c538fb55bf12@haskell.org> References: <044.12e90915219726766b58c538fb55bf12@haskell.org> Message-ID: <059.2128127f0d68e7101fd05a3fbff99955@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:20 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:20 -0000

#8416: GHC.Generics needs more documentation --------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Documentation bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by refold): * component: libraries (other) => libraries/base -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8416#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Mon Oct 7 16:39:11 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 16:39:11 -0000 Subject: [GHC] #8417: Pattern matching on OverloadedLists is erratic Message-ID: <047.115f74871856b9eb9aefa12724dca3f3@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:20 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:20 -0000

#8417: Pattern matching on OverloadedLists is erratic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC accepts Architecture: Unknown/Multiple | invalid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Consider {{{ ?> :set -XOverloadedLists ?> :t \[True] -> 'a' \[True] -> 'a' :: (GHC.Exts.IsList l, GHC.Exts.Item l ~ Bool) => l -> Char ?> :t \[not] -> 'a' \[not] -> 'a' :: GHC.Exts.IsList l => l -> Char }}} The first type is expected, but the second one should include `GHC.Exts.Item l ~ Bool -> Bool` and `Eq (Bool -> Bool)`. Currently e.g. `(\[not] -> True) [id]` evaluates to `True`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8417 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Mon Oct 7 17:11:20 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 17:11:20 -0000 Subject: [GHC] #8417: Pattern matching on OverloadedLists is erratic In-Reply-To: <047.115f74871856b9eb9aefa12724dca3f3@haskell.org> References: <047.115f74871856b9eb9aefa12724dca3f3@haskell.org> Message-ID: <062.25db277d9e459d4501fcf67780506602@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:20 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:20 -0000

#8417: Pattern matching on OverloadedLists is erratic ------------------------------------------------+-------------------------- Reporter: monoidal | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts invalid program | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by monoidal): * status: new => closed * resolution: => invalid Comment: I'm wrong, `not` works as a wildcard pattern. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8417#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Mon Oct 7 17:24:29 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 17:24:29 -0000 Subject: [GHC] #8380: Numerous testsuite failures on ARM due to missing mkJumpToAddr In-Reply-To: <046.6822dd2c7a2b1392cbd1b6deb902b274@haskell.org> References: <046.6822dd2c7a2b1392cbd1b6deb902b274@haskell.org> Message-ID: <061.f8927a1e35d627ecaeeba12caaee3180@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:20 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:20 -0000

#8380: Numerous testsuite failures on ARM due to missing mkJumpToAddr -------------------------------------+--------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: patch Operating System: Unknown/Multiple | Architecture: arm Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+--------------------------- Comment (by thoughtpolice): Actually, I was missing something when I dove into the code. :) We actually need `ffi_prep_closure_loc` in order to clear the cache for us on ARM, which we don't do in the `allocateExec` path. In which case, we need to flush the cache explicitly. I'm bumping the priority on this since it's perhaps the biggest bug left for ARM. I'll integrate Ben's mkJumpToAddr patch and double check we clear things appropriately. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8380#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Mon Oct 7 17:25:08 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 17:25:08 -0000 Subject: [GHC] #8380: Numerous testsuite failures on ARM due to missing mkJumpToAddr In-Reply-To: <046.6822dd2c7a2b1392cbd1b6deb902b274@haskell.org> References: <046.6822dd2c7a2b1392cbd1b6deb902b274@haskell.org> Message-ID: <061.6c0ebfffe7eddc31c7169daee906bd11@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:20 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:20 -0000

#8380: Numerous testsuite failures on ARM due to missing mkJumpToAddr -------------------------------------+--------------------------------- Reporter: bgamari | Owner: thoughtpolice Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: patch Operating System: Unknown/Multiple | Architecture: arm Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+--------------------------------- Changes (by thoughtpolice): * owner: bgamari => thoughtpolice * priority: normal => highest -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8380#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Mon Oct 7 17:27:32 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 17:27:32 -0000 Subject: [GHC] #8383: "tagToEnum# (0# ==# 1#) :: Bool" causes CASEFAIL in ghci In-Reply-To: <047.66d6e6666fd83ab68f57c227d806c7ae@haskell.org> References: <047.66d6e6666fd83ab68f57c227d806c7ae@haskell.org> Message-ID: <062.bed0cd77d8e3408edb7e38e3fd721293@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:20 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:20 -0000

#8383: "tagToEnum# (0# ==# 1#) :: Bool" causes CASEFAIL in ghci ---------------------------------+---------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.7 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+---------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: Thanks for the fix, Simon! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8383#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Mon Oct 7 18:13:50 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 18:13:50 -0000 Subject: [GHC] Batch modify: #8047 Message-ID: <20131007181350.0F3EF24067@ghc.haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:20 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:20 -0000

From ghc-devs at haskell.org Mon Oct 7 18:15:29 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 18:15:29 -0000 Subject: [GHC] #8047: Implement line-number %-substitution for

Batch modification to #8047 by hvr: Action: reopen -- Tickets URL: http://ghc.haskell.org/trac/ghc/query?id=8047 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler prompt-string In-Reply-To: <042.95443be5976c93dbc31777ac77a830e7@haskell.org> References: <042.95443be5976c93dbc31777ac77a830e7@haskell.org> Message-ID: <057.933cdcabdc00de3c77533eb924c7a55c@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:21 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:21 -0000 #8047: Implement line-number %-substitution for prompt-string -------------------------------------+------------------------------------ Reporter: hvr | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by hvr): * cc: hvr (added) * status: new => closed * resolution: => fixed -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8047#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Mon Oct 7 18:29:48 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 18:29:48 -0000 Subject: [GHC] #2289: Needless reboxing of values when returning from a tight loop In-Reply-To: <043.32b2235b0e9fe1aba0c28a0cd28686b3@haskell.org> References: <043.32b2235b0e9fe1aba0c28a0cd28686b3@haskell.org> Message-ID: <058.0b38fb9457f385d047d263b21e1079f2@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:21 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:21 -0000

#2289: Needless reboxing of values when returning from a tight loop -------------------------------------+------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.8.2 Resolution: | Keywords: boxing, loops, Operating System: Unknown/Multiple | performance Type of failure: Runtime | Architecture: Unknown/Multiple performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #2387,#1600 -------------------------------------+------------------------------------- Comment (by simonpj): In fact it's orthogonal to do with loopification, which does not affect allocation. Its to do with nested CPR analysis, which I'm longing to do but keep getting diverted. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/2289#comment:36 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Mon Oct 7 22:03:04 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 22:03:04 -0000 Subject: [GHC] #3553: parallel gc suffers badly if one thread is descheduled In-Reply-To: <047.48e7cf5ad32bf05ce8bca6e11b9273f8@haskell.org> References: <047.48e7cf5ad32bf05ce8bca6e11b9273f8@haskell.org> Message-ID: <062.8e405c60ff12127d82d03105a93193be@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:21 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:21 -0000

#3553: parallel gc suffers badly if one thread is descheduled -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.2 Component: Runtime System | Version: 6.10.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by parcs): I also think it's worth noting that with the above change to `nofib/parallel/ray` applied, `yieldThread()` could be made a no-op and the runtime of the program does not change. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/3553#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Mon Oct 7 22:37:17 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 22:37:17 -0000 Subject: [GHC] #8418: [patch] comments outdated Message-ID: <044.7e7191ded062fdfcc30c9668e68cf5e6@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:21 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:21 -0000

#8418: [patch] comments outdated -------------------------------------------+------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- During working on GHC, I found these outdated comments and function names. The ForPlugins renaming is DynamicLoading.hs is motivated by the fact that chnage 57d6798 crippled the function in a way that now it can only be used while handling Plugins. Therefore the name should warn the programmer to this fact. The hptInstances comment has also been outdated, when someone needed to add the `ModuleName -> Bool` predicate to use this same function for handling ghc and ghci with shared code. The attached patch is trivial renames/comments. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8418 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Mon Oct 7 22:38:09 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 22:38:09 -0000 Subject: [GHC] #8418: [patch] comments outdated In-Reply-To: <044.7e7191ded062fdfcc30c9668e68cf5e6@haskell.org> References: <044.7e7191ded062fdfcc30c9668e68cf5e6@haskell.org> Message-ID: <059.1e5867b710ae65fe7627555f77e14ce6@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:21 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:21 -0000

#8418: [patch] comments outdated -------------------------------+------------------------------------------- Reporter: errge | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by errge): * status: new => patch -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8418#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Mon Oct 7 22:59:00 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 22:59:00 -0000 Subject: [GHC] #8048: Register spilling produces ineffecient/highly contending code In-Reply-To: <046.812a6c0f95e2954ecf561f3e19f7d22f@haskell.org> References: <046.812a6c0f95e2954ecf561f3e19f7d22f@haskell.org> Message-ID: <061.341cc4e46bbb5524b876854a4bda3529@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:21 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:21 -0000

#8048: Register spilling produces ineffecient/highly contending code -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 7.6.3 Resolution: | Keywords: register Operating System: Unknown/Multiple | allocator spill Type of failure: Runtime | Architecture: Unknown/Multiple performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by schyler): Using a pretty crude benchmark, found a 9-10% hit. https://gist.github.com/kvanberendonck/6836713 It's hard to benchmark something so small though - those of you with Intel processors might have less luck running this one, but AMD is a little more linear and gives quite stable results. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8048#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Mon Oct 7 22:59:35 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 22:59:35 -0000 Subject: [GHC] #8418: [patch] comments outdated In-Reply-To: <044.7e7191ded062fdfcc30c9668e68cf5e6@haskell.org> References: <044.7e7191ded062fdfcc30c9668e68cf5e6@haskell.org> Message-ID: <059.26b316f4678a29f154004c177e95bfbd@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:21 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:21 -0000

#8418: [patch] comments outdated -------------------------------+------------------------------------------- Reporter: errge | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Description changed by hvr: Old description:

During working on GHC, I found these outdated comments and function names.

The ForPlugins renaming is DynamicLoading.hs is motivated by the fact that chnage 57d6798 crippled the function in a way that now it can only be used while handling Plugins. Therefore the name should warn the programmer to this fact.

The hptInstances comment has also been outdated, when someone needed to add the `ModuleName -> Bool` predicate to use this same function for handling ghc and ghci with shared code.

The attached patch is trivial renames/comments.

From ghc-devs at haskell.org Mon Oct 7 23:03:12 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 23:03:12 -0000 Subject: [GHC] #8272: testing if SpLim=$rbp and Sp=$rsp changed

New description: During working on GHC, I found these outdated comments and function names. The `ForPlugins` renaming in [[GhcFile(compiler/main/DynamicLoading.hs)]] is motivated by the fact that change [57d67983] crippled the function in a way that now it can only be used while handling Plugins. Therefore the name should warn the programmer to this fact. The hptInstances comment has also been outdated, when someone needed to add the `ModuleName -> Bool` predicate to use this same function for handling ghc and ghci with shared code. The attached patch is trivial renames/comments. -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8418#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler performance at all In-Reply-To: <045.ecd7af4f53d7df1147bf6a068ec1e485@haskell.org> References: <045.ecd7af4f53d7df1147bf6a068ec1e485@haskell.org> Message-ID: <060.c1c5cd2b2a2a2dd7e0b20d9bfb0a4072@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:21 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:21 -0000 #8272: testing if SpLim=$rbp and Sp=$rsp changed performance at all -------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: callingConvention Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Rocket Science Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by schyler): It's possible this could fix #8048 or at least allow better/smarter code to be generated for spills. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8272#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Mon Oct 7 23:06:44 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 23:06:44 -0000 Subject: [GHC] #8048: Register spilling produces ineffecient/highly contending code In-Reply-To: <046.812a6c0f95e2954ecf561f3e19f7d22f@haskell.org> References: <046.812a6c0f95e2954ecf561f3e19f7d22f@haskell.org> Message-ID: <061.79a8b9c4fb2fe7da689efef72fa80287@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:22 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:22 -0000

From ghc-devs at haskell.org Mon Oct 7 23:07:07 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 23:07:07 -0000 Subject: [GHC] #8272: testing if SpLim=$rbp and Sp=$rsp changed

#8048: Register spilling produces ineffecient/highly contending code -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 7.6.3 Resolution: | Keywords: register Operating System: Unknown/Multiple | allocator spill Type of failure: Runtime | Architecture: Unknown/Multiple performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by schyler): * cc: schyler (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8048#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler performance at all In-Reply-To: <045.ecd7af4f53d7df1147bf6a068ec1e485@haskell.org> References: <045.ecd7af4f53d7df1147bf6a068ec1e485@haskell.org> Message-ID: <060.5de5a855339b51d513db549db2c6e388@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:22 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:22 -0000 #8272: testing if SpLim=$rbp and Sp=$rsp changed performance at all -------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: callingConvention Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Rocket Science Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by schyler): * cc: schyler (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8272#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Mon Oct 7 23:13:27 2013 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Oct 2013 23:13:27 -0000 Subject: [GHC] #8419: add rawSystem variant that takes an environment Message-ID: <044.1336ed0d15ff978db053dbcdcdc7efa1@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:22 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:22 -0000

#8419: add rawSystem variant that takes an environment -------------------------------------+------------------------------------- Reporter: dagit | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/process | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- rawSystem properly handles the case of ^C while waiting. Instead of requiring people to recreate this behavior when using runProcess, it would be good if we add and export a rawSystemWithEnv or directly export syncProcess. See for example: https://github.com/haskell/cabal/issues/1448 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8419 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 8 01:02:19 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Oct 2013 01:02:19 -0000 Subject: [GHC] #8420: Spurious dynamic library dependencies Message-ID: <053.6d20c8a5a1dda98693fe4739c5ec23a3@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:22 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:22 -0000

#8420: Spurious dynamic library dependencies ------------------------------------+--------------------------------- Reporter: AndreasVoellmy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- It should be possible to have an executable A that depends on dynamic library B which in turn depends on dynamic library C, without A directly depending on C. {{{ A --> B --> C }}} Unfortunately, GHC 7.6.3 does not seem to allow this. Instead it copies the dependencies of B to dependencies of A, so that we get {{{ A -> B,C and B --> C }}} This is unfortunately, because running A will cause the loader to locate C based on the rpaths (assuming we are using rpaths to locate dynamic libraries), whereas only B should know how to get to C from B. The problem seems to be that ghc copies all the library dependencies of B (presumably from the package specification of B) as library dependencies of the A. I verified the problem in GHC 7.6.3, but haven't tried in HEAD yet. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8420 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 8 07:54:32 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Oct 2013 07:54:32 -0000 Subject: [GHC] #3553: parallel gc suffers badly if one thread is descheduled In-Reply-To: <047.48e7cf5ad32bf05ce8bca6e11b9273f8@haskell.org> References: <047.48e7cf5ad32bf05ce8bca6e11b9273f8@haskell.org> Message-ID: <062.4acaba8134fc152e32c632a6ecdf5b6a@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:22 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:22 -0000

#3553: parallel gc suffers badly if one thread is descheduled -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.2 Component: Runtime System | Version: 6.10.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): Interesting - I hadn't realised that the main thread being bound could affect the performance of ordinary parallel programs too. I'm very tempted to change the main thread to be non-bound. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/3553#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 8 07:57:57 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Oct 2013 07:57:57 -0000 Subject: [GHC] #7767: "internal error: evacuate: strange closure type 154886248" crash In-Reply-To: <047.0b39935f5cb7eca0e8f06868adf551de@haskell.org> References: <047.0b39935f5cb7eca0e8f06868adf551de@haskell.org> Message-ID: <062.957184c7a50d528d61107b079b463316@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:22 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:22 -0000

#7767: "internal error: evacuate: strange closure type 154886248" crash -----------------------------------+---------------------------------- Reporter: rodlogic | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Comment (by simonmar): reading the above comments, this still looks like a feature request to me. @schyler, did you change it to "bug" for a reason? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7767#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 8 14:33:26 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Oct 2013 14:33:26 -0000 Subject: [GHC] #8402: throwTo segfaults under -prof -threaded -with-rtsopts=N2 In-Reply-To: <043.0ab089710edd4b363b63a9d75aa20e5f@haskell.org> References: <043.0ab089710edd4b363b63a9d75aa20e5f@haskell.org> Message-ID: <058.002fd80bbf8c78595d09b21f733e993a@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:22 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:22 -0000

#8402: throwTo segfaults under -prof -threaded -with-rtsopts=N2 ----------------------------------+---------------------------------- Reporter: akio | Owner: simonmar Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Profiling | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by simonmar): * owner: => simonmar Comment: ezyang: I think the case that you were originally trying to fix by removing the test was PROFILING && DEBUG, right? We need to restore the original check to fix this bug, and additionally enable slop-zeroing when PROFILING && DEBUG. I'll commit a fix. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8402#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 8 14:40:42 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Oct 2013 14:40:42 -0000 Subject: [GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?) In-Reply-To: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> References: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> Message-ID: <062.c7a6988c7517774fed62ff12b2246d00@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:22 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:22 -0000

#7602: Threaded RTS performing badly on recent OS X (10.8?) -----------------------------------+---------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 7678 Blocking: | Related Tickets: -----------------------------------+---------------------------------- Comment (by simonmar): If somebody makes a patch to pass around `gct` explicitly, and it doesn't degrade performance on Linux, then I wouldn't object to putting it in. It would be good to remove our reliance on thread-local state, at the expense of a bit of extra code cruft. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7602#comment:30 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 8 15:58:10 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Oct 2013 15:58:10 -0000 Subject: [GHC] #8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault In-Reply-To: <046.a1de52e736c53bf94deece978e2702d5@haskell.org> References: <046.a1de52e736c53bf94deece978e2702d5@haskell.org> Message-ID: <061.2f9628ffb3a54624a20bcbdb48c4ee3c@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:22 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:22 -0000

#8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------+---------------------------------- Reporter: darchon | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8376#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 8 15:58:29 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Oct 2013 15:58:29 -0000 Subject: [GHC] #2595: Implement record update for existential and GADT data types In-Reply-To: <046.4aca36ddfd3abd8f80e6714ed9319183@haskell.org> References: <046.4aca36ddfd3abd8f80e6714ed9319183@haskell.org> Message-ID: <061.a5f28df33c0171ef790e74e82446a48f@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:22 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:22 -0000

#2595: Implement record update for existential and GADT data types -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: tc244 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by byorgey): * cc: byorgey@? (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/2595#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 8 16:54:49 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Oct 2013 16:54:49 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.df7bb8d3ef749d16c1361797034216b4@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:23 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:23 -0000

#7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): Another example {{{ data T a = forall a. MkT a }}} The inner `a` shadows the outer one, so this really means: {{{ data T a where MkT :: forall b. b -> T a }}} but it displays as {{{ data T a where MkT :: a -> T a }}} which is desperately confusing. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7730#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 8 17:34:44 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Oct 2013 17:34:44 -0000 Subject: [GHC] #7767: "internal error: evacuate: strange closure type 154886248" crash In-Reply-To: <047.0b39935f5cb7eca0e8f06868adf551de@haskell.org> References: <047.0b39935f5cb7eca0e8f06868adf551de@haskell.org> Message-ID: <062.dc90a6950c9087b041dfad68ebcc6e86@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:23 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:23 -0000

#7767: "internal error: evacuate: strange closure type 154886248" crash ------------------------------------+---------------------------------- Reporter: rodlogic | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+---------------------------------- Changes (by carter): * type: bug => feature request Comment: @Simon, I suspect schyler made a mistake on that note. So this ticket it about the possibility of exposing a GHC api to better support writing Heap introspection tools right? Should we split that out into its own ticket as a somewhat clearer feature request that cites this ticket? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7767#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 8 17:36:49 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Oct 2013 17:36:49 -0000 Subject: [GHC] #8276: Building Haddock documentation panics with perf build on x86_64 Linux In-Reply-To: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> References: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> Message-ID: <063.e0117e5abd556f8a16ca3bc09ecfc852@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:23 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:23 -0000

#8276: Building Haddock documentation panics with perf build on x86_64 Linux ---------------------------------------+---------------------------------- Reporter: jstolarek | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Documentation | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by carter): whats the current status of this ticket? Its affecting LOTs of people? Whats needed to push it along? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8276#comment:32 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 8 18:28:36 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Oct 2013 18:28:36 -0000 Subject: [GHC] #8421: ghc build failure with template haskell on ghc head Message-ID: <045.ea1628dce7af519cd36fc44039de3371@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:23 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:23 -0000

#8421: ghc build failure with template haskell on ghc head ----------------------------------+---------------------------------------- Reporter: schell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------------- It seems that it failed while building template haskell with this output: {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-name ghc-7.7.20131008 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -icompiler/stage2/build/autogen -Icompiler/stage2/build -Icompiler/stage2/build/autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -optP- DGHCI -optP-include -optPcompiler/stage2/build/autogen/cabal_macros.h -package Cabal-1.18.1 -package array-0.4.0.2 -package base-4.7.0.0 -package bin-package-db-0.0.0.0 -package bytestring-0.10.3.0 -package containers-0.5.3.1 -package directory-1.2.0.1 -package filepath-1.3.0.2 -package hoopl-3.10.0.0 -package hpc-0.6.0.1 -package process-1.2.0.0 -package template-haskell-2.9.0.0 -package time-1.4.1 -package transformers-0.3.0.0 -package unix-2.7.0.0 -Wall -fno-warn-name-shadowing -XHaskell98 -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRankNTypes -XScopedTypeVariables -XDeriveDataTypeable -XBangPatterns -XNondecreasingIndentation -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -O2 -no-user-package-db -rtsopts -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -dynamic-too -c compiler/typecheck/TcSplice.lhs -o compiler/stage2/build/TcSplice.o -dyno compiler/stage2/build/TcSplice.dyn_o compiler/typecheck/TcSplice.lhs:1068:3: ?qAddTopDecls? is not a (visible) method of class ?TH.Quasi? compiler/typecheck/TcSplice.lhs:1099:3: ?qAddModFinalizer? is not a (visible) method of class ?TH.Quasi? compiler/typecheck/TcSplice.lhs:1103:3: ?qGetQ? is not a (visible) method of class ?TH.Quasi? compiler/typecheck/TcSplice.lhs:1109:3: ?qPutQ? is not a (visible) method of class ?TH.Quasi? make[1]: *** [compiler/stage2/build/TcSplice.o] Error 1 make: *** [all] Error 2 }}} Here is my gcc -v: {{{ schell at localhost:~/C/ghc:master$ gcc -v Using built-in specs. Target: i686-apple-darwin11 Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/src/configure --disable- checking --enable-werror --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program- prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with- slibdir=/usr/lib --build=i686-apple-darwin11 --enable- llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/dst- llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx- include-dir=/usr/include/c++/4.2.1 Thread model: posix gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) }}} I'm on Mac OS X 10.8.5. Before fast forwarding to HEAD I was encountering #8276 though I don't know if this build got further or less far :(. I'm attaching what I hope is the ghc fingerprint I got using ./utils/fingerprint/fingerprint.py create -o fingerprint.log... -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8421 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 8 18:47:32 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Oct 2013 18:47:32 -0000 Subject: [GHC] #8421: ghc build failure with template haskell on ghc head In-Reply-To: <045.ea1628dce7af519cd36fc44039de3371@haskell.org> References: <045.ea1628dce7af519cd36fc44039de3371@haskell.org> Message-ID: <060.c4c213c64bc43f6c2a85241987e8616e@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:23 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:23 -0000

#8421: ghc build failure with template haskell on ghc head ----------------------------------------+---------------------------------- Reporter: schell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by parcs): Judging by the fingerprint, your `libraries/template-haskell` is not up- to-date. Did you forget to run `./sync-all pull`? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8421#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 8 19:10:05 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Oct 2013 19:10:05 -0000 Subject: [GHC] #8043: Feature Request : Qualified module exports In-Reply-To: <044.7e67fd67a3a24a755f819579ca8418d3@haskell.org> References: <044.7e67fd67a3a24a755f819579ca8418d3@haskell.org> Message-ID: <059.210540c95386589129d6ebd64581b216@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:23 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:23 -0000

#8043: Feature Request : Qualified module exports -------------------------------------+------------------------------------ Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): This may be the new location for that discussion: http://www.haskell.org/pipermail/libraries/2005-March/003139.html Could someone please fix the mailing list links! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8043#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 8 19:23:42 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Oct 2013 19:23:42 -0000 Subject: [GHC] #7783: MultiWayIf should start a new layout In-Reply-To: <044.4f2ebc6f2a6763cb3be79faa05da1543@haskell.org> References: <044.4f2ebc6f2a6763cb3be79faa05da1543@haskell.org> Message-ID: <059.5397045b9331a7a3383f97577467f1e2@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:23 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:23 -0000

#7783: MultiWayIf should start a new layout --------------------------------------+------------------------------------ Reporter: exbb2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Parser) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #4359 --------------------------------------+------------------------------------ Comment (by Simon Marlow ): In [changeset:"d2013e85976cccde6c915211f8bcc26f2dc93e33/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d2013e85976cccde6c915211f8bcc26f2dc93e33" docs for new layout behaviour with MultiWayIf (#7783) }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7783#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 8 19:24:18 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Oct 2013 19:24:18 -0000 Subject: [GHC] #7783: MultiWayIf should start a new layout In-Reply-To: <044.4f2ebc6f2a6763cb3be79faa05da1543@haskell.org> References: <044.4f2ebc6f2a6763cb3be79faa05da1543@haskell.org> Message-ID: <059.99f0092008700dc95ff01bea66267bdb@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:23 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:23 -0000

#7783: MultiWayIf should start a new layout --------------------------------------+------------------------------------ Reporter: exbb2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler (Parser) | Version: 7.6.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #4359 --------------------------------------+------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7783#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 8 20:45:59 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Oct 2013 20:45:59 -0000 Subject: [GHC] #8276: Building Haddock documentation panics with perf build on x86_64 Linux In-Reply-To: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> References: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> Message-ID: <063.88711423a201c52b88bf397ccd53bd8d@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:24 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:24 -0000

#8276: Building Haddock documentation panics with perf build on x86_64 Linux ---------------------------------------+---------------------------------- Reporter: jstolarek | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Documentation | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by SimonHengel): Austin, do you think what I proposed for the Haddock side of things is the way to go? I'm still puzzled what triggered the issue. A couple of weeks ago the documentation still build for me. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8276#comment:33 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 8 21:02:58 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Oct 2013 21:02:58 -0000 Subject: [GHC] #8422: type nats solver is too weak! Message-ID: <045.a8bed5de254996d75b3b1116e9b1eced@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:24 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:24 -0000

#8422: type nats solver is too weak! -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler (Type | Version: 7.7 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: Unknown/Multiple | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- I just built ghc HEAD today, and the type nat solver can't handle the attached program, which *should* be simple to check! (and while I could use unsafeCoerce to "prove" it correct, that defeats the purpose of having the type nat solver!) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8422 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 8 21:07:13 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Oct 2013 21:07:13 -0000 Subject: [GHC] #8422: type nats solver is too weak! In-Reply-To: <045.a8bed5de254996d75b3b1116e9b1eced@haskell.org> References: <045.a8bed5de254996d75b3b1116e9b1eced@haskell.org> Message-ID: <060.43473bb7451ec833825e1075bc7950ca@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:24 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:24 -0000

#8422: type nats solver is too weak! ----------------------------------------------+---------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by carter): the error in question is {{{ Fancy.hs:58:35: Could not deduce ((r2 + (1 + b)) ~ (a + b)) from the context (r ~ (1 + r1)) bound by a pattern with constructor :* :: forall (r :: Nat). Int -> Shape r -> Shape (1 + r), in an equation for ?reverseShape? at Fancy.hs:54:19-30 or from (a ~ (1 + r2)) bound by a pattern with constructor :* :: forall (r :: Nat). Int -> Shape r -> Shape (1 + r), in an equation for ?go? at Fancy.hs:58:13-22 NB: ?+? is a type function, and may not be injective Expected type: Shape (a + b) Actual type: Shape (r2 + (1 + b)) Relevant bindings include res :: Shape b (bound at Fancy.hs:58:27) more :: Shape r2 (bound at Fancy.hs:58:19) go :: Shape a -> Shape b -> Shape (a + b) (bound at Fancy.hs:57:9) In the expression: go more (ix :* res) In an equation for ?go?: go (ix :* more) res = go more (ix :* res) }}} in one case , the solver should be able to deduce that 0+b = b ===> b = r and in the other case that a = a_1+1 then (a+b =r ) implies a_1 + b +1=r or something like that -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8422#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 8 22:00:56 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Oct 2013 22:00:56 -0000 Subject: [GHC] #8423: contraint solver doesn't reduce reducible closed type family expressions (even with undecidable instances!) Message-ID: <045.e519cd37d8a4b1c71c71d8593787d92e@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:24 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:24 -0000

#8423: contraint solver doesn't reduce reducible closed type family expressions (even with undecidable instances!) -------------------------------------------+------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- attached is an example where the type checker isn't "computing" in the closed type families, or at least doing a one step reduction. this makes sense, given that type families only compute when instantiated... But if we could partially evaluate closed type families (or at least do a one step reduction), the attached example code would type check! interestingly, depending on what order the cases for the PSum are written, the type error changes! I guess I want an "eager matching" closed type family, that when partially instantiated will patch on the first pattern it satisfies, to complement ordered type families. attached is a toy example where I otherwise need an unsafeCoerce to make things type check -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8423 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 8 22:03:57 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Oct 2013 22:03:57 -0000 Subject: [GHC] #8423: contraint solver doesn't reduce reducible closed type family expressions (even with undecidable instances!) In-Reply-To: <045.e519cd37d8a4b1c71c71d8593787d92e@haskell.org> References: <045.e519cd37d8a4b1c71c71d8593787d92e@haskell.org> Message-ID: <060.cffaf67a4fd76a76895c76b1dca9c64f@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:24 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:24 -0000

#8423: contraint solver doesn't reduce reducible closed type family expressions (even with undecidable instances!) --------------------------------------------+------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by carter): so maybe this is a "feature request" idea rather than a bug, but i'd like more folks to chime in please :) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8423#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 8 22:16:11 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Oct 2013 22:16:11 -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.706740cda198f7dc1835c3ee06c7f73b@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:24 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:24 -0000

#7919: Heap corruption (segfault) from large 'let' expression -----------------------------------+---------------------------------- Reporter: duncan | Owner: simonmar Type: bug | Status: merge Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Changes (by george.colpitts): * cc: simonmar (added) Comment: Shouldn't the status be infoneeded rather than merge? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7919#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Tue Oct 8 22:19:14 2013 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Oct 2013 22:19:14 -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.74df38529153c2636c38ec69883246b0@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:24 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:24 -0000

#7919: Heap corruption (segfault) from large 'let' expression -----------------------------------+---------------------------------- Reporter: duncan | Owner: simonmar Type: bug | Status: merge Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Changes (by george.colpitts): * cc: george.colpitts@? (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7919#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 01:41:51 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 01:41:51 -0000 Subject: [GHC] #8423: contraint solver doesn't reduce reducible closed type family expressions (even with undecidable instances!) In-Reply-To: <045.e519cd37d8a4b1c71c71d8593787d92e@haskell.org> References: <045.e519cd37d8a4b1c71c71d8593787d92e@haskell.org> Message-ID: <060.b537067dccb0778bde0bb41c0e49ad0d@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:24 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:24 -0000

#8423: contraint solver doesn't reduce reducible closed type family expressions (even with undecidable instances!) --------------------------------------------+------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by carter): * type: bug => feature request * milestone: 7.8.1 => 7.10.1 Comment: Though I imagine theres some subtleties to adding such machinery, but it might be a great way to allow more "proofs by computation" to work out in Haskell -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8423#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 01:54:51 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 01:54:51 -0000 Subject: [GHC] #8422: type nats solver is too weak! In-Reply-To: <045.a8bed5de254996d75b3b1116e9b1eced@haskell.org> References: <045.a8bed5de254996d75b3b1116e9b1eced@haskell.org> Message-ID: <060.4a6f04e4d60af07252d7119dab34936e@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:24 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:24 -0000

#8422: type nats solver is too weak! ----------------------------------------------+---------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by carter): i tried getting solver example in the status report to work, and it doesn't :( http://ghc.haskell.org/trac/ghc/wiki/Status/Oct13 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8422#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 02:18:06 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 02:18:06 -0000 Subject: [GHC] #8423: contraint solver doesn't reduce reducible closed type family expressions (even with undecidable instances!) In-Reply-To: <045.e519cd37d8a4b1c71c71d8593787d92e@haskell.org> References: <045.e519cd37d8a4b1c71c71d8593787d92e@haskell.org> Message-ID: <060.6e9ac992eb3882485679043499e70f42@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:24 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:24 -0000

#8423: contraint solver doesn't reduce reducible closed type family expressions (even with undecidable instances!) --------------------------------------------+------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #4259 --------------------------------------------+------------------------------ Changes (by goldfire): * related: => #4259 Comment: Yes, closed type families are too weak. But for a good reason. Here is the test case boiled down: {{{ data PNat = S !PNat | Z type family PSum (a :: PNat) (b:: PNat) :: PNat where PSum 'Z b = b -- 1 PSum a 'Z = a -- 2 PSum a ('S b) = 'S (PSum a b) -- 3 PSum ('S a) b = 'S (PSum a b) -- 4 }}} At some point, the type checker wants to know whether `(PSum (S r2) b) ~ (PSum r2 (S b))`. To do this, both sides of the `~` need to reduce one step. But neither can reduce in practice. Why? An equation in a closed type family can fire (that is, be used in a reduction) only when GHC can be absolutely positive of one of two things: 1. No previous equation can fire, or 2. Any previous equation that can fire will reduce, in one step, to the same thing. (Technically, (2) subsumes (1), but it's easier to think about the cases separately.) Let's consider reducing `PSum r2 (S b)`. Clearly, neither of the first two equations are applicable. Equally clearly, the third equation is quite tempting. Now, we check for these conditions. We quickly see that equation (1) might fire, if `r2` ends up becoming `Z`. So, now we need to satisfy (2). If equation (1) can fire, then we really are in the case `PSum Z (S b)`. If equation (1) fires, we get `S b`. If equation (3) fires, we get `S (PSum Z b)`. These are '''not''' the same. So, GHC remains on the fence about the whole affair and prudently refuses to take action. An obvious question at this point is: Why the one-step restriction? The answer: anything else is not obviously well-founded. (Note: I did not say "obviously not well-founded", which is quite a different claim!) The general case is to check that the reducts (that is, the right-hand sides) are ''confluent''. (The current check looks to see if they are ''coincident''.) But, to check confluence means reasoning about type family reductions... including perhaps the one we are defining... whose reduction behavior would depend on the confluence of the equations' right- hand sides. Oops; we've just fallen into the rabbit hole. There might be a way out of this morass, but I go cross-eyed when I think about it for too long. Not that it isn't worth it -- I think that allowing code like Carter's to be accepted would be a great boon to GHC! I just don't know a way of thinking about this that will solve the problem. For more reading on the subject, check out #4259, which is all about this problem. It's possible that closed type families address some of the examples there, but the core problem discussed in that bug is the same as the one here. However, because that bug is about open families and this one is about closed, I will leave this one open. It's (barely) conceivable that they have different solutions. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8423#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 02:19:08 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 02:19:08 -0000 Subject: [GHC] #4259: Relax restrictions on type family instance overlap In-Reply-To: <044.e5eb645c3ea4a197b93ff685f55f7550@haskell.org> References: <044.e5eb645c3ea4a197b93ff685f55f7550@haskell.org> Message-ID: <059.f89cde71d637c3d5278a5873b4f05ab4@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:24 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:24 -0000

#4259: Relax restrictions on type family instance overlap --------------------------------------------+------------------------------ Reporter: lilac | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 6.12.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8423 --------------------------------------------+------------------------------ Changes (by goldfire): * related: => #8423 Comment: See also #8423 to see an example of this issue in action in the context of closed type families. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/4259#comment:30 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 02:47:08 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 02:47:08 -0000 Subject: [GHC] #3553: parallel gc suffers badly if one thread is descheduled In-Reply-To: <047.48e7cf5ad32bf05ce8bca6e11b9273f8@haskell.org> References: <047.48e7cf5ad32bf05ce8bca6e11b9273f8@haskell.org> Message-ID: <062.1a83bec7c6d32d14c276f2eb94f51106@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:25 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:25 -0000

#3553: parallel gc suffers badly if one thread is descheduled -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.2 Component: Runtime System | Version: 6.10.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by parcs): Replying to [comment:13 simonmar]:

I'm very tempted to change the main thread to be non-bound.

If so, would the earlier commits that helped mitigate this particular slowdown be undone? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/3553#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 03:09:28 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 03:09:28 -0000 Subject: [GHC] #8424: quasi-quotes have carriage returns on Windows Message-ID: <048.22a0e52e93667b75ca5f688b556e6150@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:25 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:25 -0000

#8424: quasi-quotes have carriage returns on Windows ------------------------------------+------------------------------------- Reporter: GregWeber | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- A Windows user rerported using Data.Text.IO.writeFile to write out quasi- quoted text. writeFile automatically translates '\r' to "\r\n", so the user ended up writing out "\r\r\n" to a file. Haskell seems to be adopting the policy or removing '\r' from Haskell land. Is there any reason why quasi-quotes should not automatically strip carriage returns? I asked this question on ghc-users and there was no response. I am willing to make this fix if it is deemed appropriate. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8424 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 03:15:30 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 03:15:30 -0000 Subject: [GHC] #8424: quasi-quotes have carriage returns on Windows In-Reply-To: <048.22a0e52e93667b75ca5f688b556e6150@haskell.org> References: <048.22a0e52e93667b75ca5f688b556e6150@haskell.org> Message-ID: <063.17b24886857ce673814d5fd1a6e4adc0@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:25 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:25 -0000

#8424: quasi-quotes have carriage returns on Windows -------------------------------------+------------------------------------ Reporter: GregWeber | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rwbarton): This is talking about a source file like {{{ multilineString :: String multilineString = [q|foo bar baz|] }}} right? I'm surprised the '\r's don't get stripped out when GHC reads the source file, is it opening it in binary mode? Should it be? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8424#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 03:45:41 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 03:45:41 -0000 Subject: [GHC] #8367: putStrLn and related printing functions don't output to MinTTY properly under Windows In-Reply-To: <046.2951117840610b0c0519f1700567b124@haskell.org> References: <046.2951117840610b0c0519f1700567b124@haskell.org> Message-ID: <061.1da43de9858661aa964d1c266d880604@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:25 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:25 -0000

#8367: putStrLn and related printing functions don't output to MinTTY properly under Windows ----------------------------+---------------------------------------------- Reporter: schyler | Owner: schyler Type: bug | Status: new Priority: high | Milestone: Component: Runtime | Version: 7.6.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Moderate (less than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by schyler): Solved the problem - for some reason it doesn't flush properly on MinTTY. Consider; {{{ -- Small case for #8367 import Control.Monad import System.IO main = do -- Print something intelligent putStrLn $ "People assume that time is a strict progression of cause " ++ "to effect, but *actually* from a non-linear, non-subjective " ++ "viewpoint - it's more like a big ball of wibbly wobbly " ++ "time-y wimey... stuff." -- Uncomment this line to see terminal output -- hFlush stdout -- Do some pointless logic so the program doesn't terminate and -- hence we won't see a buffer flush. forever $ return () }}} {{{ #include int main() { printf("hello"); //fflush(stdout); while (1); return 0; } }}} Neither of these work with fflush. Seems to probably be an issue with MinTTY/mingw sh, so I'm just going to set to wontfix. :( -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8367#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 03:47:14 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 03:47:14 -0000 Subject: [GHC] #8367: putStrLn and related printing functions don't output to MinTTY properly under Windows In-Reply-To: <046.2951117840610b0c0519f1700567b124@haskell.org> References: <046.2951117840610b0c0519f1700567b124@haskell.org> Message-ID: <061.16b10529eba72e03a5d87aa2a7e088f1@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:25 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:25 -0000

#8367: putStrLn and related printing functions don't output to MinTTY properly under Windows ----------------------------+---------------------------------------------- Reporter: schyler | Owner: schyler Type: bug | Status: closed Priority: high | Milestone: Component: Runtime | Version: 7.6.3 System | Keywords: Resolution: wontfix | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Moderate (less than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | ----------------------------+---------------------------------------------- Changes (by schyler): * status: new => closed * resolution: => wontfix -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8367#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 03:57:28 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 03:57:28 -0000 Subject: [GHC] #8367: putStrLn and related printing functions don't output to MinTTY properly under Windows In-Reply-To: <046.2951117840610b0c0519f1700567b124@haskell.org> References: <046.2951117840610b0c0519f1700567b124@haskell.org> Message-ID: <061.e4c42860ad5b9b122cb77acee4555ce4@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:25 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:25 -0000

#8367: putStrLn and related printing functions don't output to MinTTY properly under Windows ----------------------------+---------------------------------------------- Reporter: schyler | Owner: schyler Type: bug | Status: closed Priority: high | Milestone: Component: Runtime | Version: 7.6.3 System | Keywords: Resolution: wontfix | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Moderate (less than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by schyler): https://code.google.com/p/mintty/issues/detail?id=56 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8367#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 04:48:47 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 04:48:47 -0000 Subject: [GHC] #8423: contraint solver doesn't reduce reducible closed type family expressions (even with undecidable instances!) In-Reply-To: <045.e519cd37d8a4b1c71c71d8593787d92e@haskell.org> References: <045.e519cd37d8a4b1c71c71d8593787d92e@haskell.org> Message-ID: <060.fcf3602ea3e86beb39a8caed7d6579df@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:25 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:25 -0000

#8423: contraint solver doesn't reduce reducible closed type family expressions (even with undecidable instances!) --------------------------------------------+------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #4259 --------------------------------------------+------------------------------ Comment (by carter): excellent points that i probably agree with (and i'll have to dig into that other ticket as time permits) Hrm, another way of looking at it is that i'd be ok with having to come up with sort of induction principles or the like that let me give the type checker the proofs! Currently we dont have a decent story that plays well with equality constraints. so I either need to "lie about the types" and do something like {{{ reverseShape :: Shape r -> Shape r reverseShape Nil = Nil reverseShape shs@(anIx :* rest) = go shs Nil where --- too weakly typed go :: Shape a -> Shape b -> Shape r -- want r= PSum a b go Nil res = unsafeCoerce $ res -- 0 + b = b ==> b=r go (ix :* more ) res = go more (ix :* res) --- 1+a + b = r }}} (which has a cast in the base case, but is ok othewise) OR try to have some sort of "proof" mapping, which honestly dones't work, and to even "write" the terms required {{{ {-# LANGUAGE AllowAmbiguousTypes #-} }}} that attempt looked like the following {{{ assocSumSucc :: Shape (PSum ('S r2) b) -> Shape ( PSum r2 ('S b)) assocSumSucc = unsafeCoerce assocSumSuccBad :: Shape (PSum a b) -> Shape ( PSum c d) assocSumSuccBad = unsafeCoerce }}} this doesn't quite work, because neither interacts with the equality constraint solving! So the only sane thing of that sort is {{{ shapeCoerce :: Shape a -> Shape b shapeCoerce = unsafeCoerce }}} which is honestly pretty bad! (and apply this in the recursive case) these as all (unlike the other solution inline above) pretty bad, because they break tail calls. I guess what i want is a way have having "proof principles" or something that i could build, which would interact well with the types. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8423#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 04:49:50 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 04:49:50 -0000 Subject: [GHC] #8423: contraint solver doesn't reduce reducible closed type family expressions (even with undecidable instances!) In-Reply-To: <045.e519cd37d8a4b1c71c71d8593787d92e@haskell.org> References: <045.e519cd37d8a4b1c71c71d8593787d92e@haskell.org> Message-ID: <060.45b62907b90fe7c19fb24c6ae4b58f37@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:25 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:25 -0000

#8423: contraint solver doesn't reduce reducible closed type family expressions (even with undecidable instances!) --------------------------------------------+------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #4259 --------------------------------------------+------------------------------ Comment (by carter): relatedly: Ranjit Jhala took the motiviating code and demo'd checking it with liquid haskell! Which is pretty darn awesome http://goto.ucsd.edu:8090/index.html#?demo=permalink%2F1381284690.hs -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8423#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 04:51:22 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 04:51:22 -0000 Subject: [GHC] #8423: contraint solver doesn't reduce reducible closed type family expressions (even with undecidable instances!) In-Reply-To: <045.e519cd37d8a4b1c71c71d8593787d92e@haskell.org> References: <045.e519cd37d8a4b1c71c71d8593787d92e@haskell.org> Message-ID: <060.34d4d99a13f3090c1c711f01a62c8035@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:26 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:26 -0000

#8423: contraint solver doesn't reduce reducible closed type family expressions (even with undecidable instances!) --------------------------------------------+------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #4259 --------------------------------------------+------------------------------ Comment (by carter): honestly i just want a way to check things, my ticket here is just noting limits that happen with type families. I'm open to anything that has a sane usability story and a sane engineering story (on the ghc and users sides both). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8423#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 06:59:01 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 06:59:01 -0000 Subject: [GHC] #8425: ghc-7.6.3: crossmodule inline leads to buggy code (-O2) Message-ID: <045.a29452ea9fbac42eef37cbddc5ab6d06@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:26 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:26 -0000

#8425: ghc-7.6.3: crossmodule inline leads to buggy code (-O2) ----------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------------- The bug is found as a crash of gf-3.4 ('Grammatical Framework') package compiled with -O2. With some debugging I've come to roughly following minimal example: This code compiles incorrectly: {{{ import BuggyOpt() -- bug inducer! import qualified Data.Map as Map import Data.Array.IArray {-# NOINLINE mkLin #-} mkLin :: Array Int (Array Int Int) -> Map.Map (Array Int Int) Int -> Int -> (Map.Map (Array Int Int) Int, Int) mkLin mseqs seqs seqid = let seq_ = mseqs ! seqid -- lookup/insert pair. exactly as in 'BuggyOpt' module in case Map.lookup seq_ seqs of Just seqid' -> (seqs,seqid') Nothing -> let seqid'' = Map.size seqs seqs' = Map.insert seq_ seqid'' seqs in (seqs',seqid'') }}} And this works fine: {{{ --import BuggyOpt() -- bug inducer! import qualified Data.Map as Map import Data.Array.IArray {-# NOINLINE mkLin #-} mkLin :: Array Int (Array Int Int) -> Map.Map (Array Int Int) Int -> Int -> (Map.Map (Array Int Int) Int, Int) mkLin mseqs seqs seqid = let seq_ = mseqs ! seqid -- lookup/insert pair. exactly as in 'BuggyOpt' module in case Map.lookup seq_ seqs of Just seqid' -> (seqs,seqid') Nothing -> let seqid'' = Map.size seqs seqs' = Map.insert seq_ seqid'' seqs in (seqs',seqid'') }}} Attached minimal test tarball and my results on it are: {{{ [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","x86_64-pc-linux-gnu-gcc") ,("C compiler flags"," -fno-stack-protector -Wl,--hash-size=31 -Wl ,--reduce-memory-overheads") ,("ar command","/usr/bin/ar") ,("ar flags","q") ,("ar supports at file","YES") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("perl command","/usr/bin/perl") ,("target os","OSLinux") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","True") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("LLVM llc command","/usr/bin/llc") ,("LLVM opt command","/usr/bin/opt") ,("Project version","7.6.3") ,("Booter version","7.6.3") ,("Stage","2") ,("Build platform","x86_64-unknown-linux") ,("Host platform","x86_64-unknown-linux") ,("Target platform","x86_64-unknown-linux") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Unregisterised","NO") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/usr/lib64/ghc-7.6.3") ,("Global Package DB","/usr/lib64/ghc-7.6.3/package.conf.d") ,("Gcc Linker flags","[\"-Wl,--hash-size=31\",\"-Wl,--reduce-memory- overheads\"]") ,("Ld Linker flags","[\"--hash-size=31\",\"--reduce-memory-overheads\"]") ] RUN good [1 of 2] Compiling Susp ( good/Susp.hs, good/Susp.o ) [2 of 2] Compiling Main ( good/main.hs, good/main.o ) Linking good/main ... (fromList [(array (0,0) [(0,42)],0)],0) RUN bad [1 of 3] Compiling BuggyOpt ( bad/BuggyOpt.hs, bad/BuggyOpt.o ) [2 of 3] Compiling Susp ( bad/Susp.hs, bad/Susp.o ) [3 of 3] Compiling Main ( bad/main.hs, bad/main.o ) Linking bad/main ... main: Error in array index; 0 not in range [0..0) TEST FAILED in bad }}} What we see here is the test with useless import mysteriously fails:

main: Error in array index; 0 not in range [0..0)

while without import it works fine:

(fromList [(array (0,0) [(0,42)],0)],0)

The functions in both BuggyOpt and Susp modules contain suspiciously similar code: {{{ case Map.lookup seq' seqs of Just id' -> (seqs,id') Nothing -> let last_seq = Map.size seqs in (Map.insert seq' last_seq seqs, last_seq) }}} But in BuggyOpt ghc somehow deduces some arguments and applies that effect to (unrelated, but looking similar) Susp module. Thanks! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8425 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 07:57:37 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 07:57:37 -0000 Subject: [GHC] #7685: :script command does not resolve ~ In-Reply-To: <046.cb641c7d9e463a4d3ab2a24ca4b94786@haskell.org> References: <046.cb641c7d9e463a4d3ab2a24ca4b94786@haskell.org> Message-ID: <061.012215c71cdc288350903e281d9cb19d@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:26 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:26 -0000

#7685: :script command does not resolve ~ -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thoughtpolice): Joachim, looks good to me. Please feel free to push it. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7685#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 08:35:47 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 08:35:47 -0000 Subject: [GHC] #7685: :script command does not resolve ~ In-Reply-To: <046.cb641c7d9e463a4d3ab2a24ca4b94786@haskell.org> References: <046.cb641c7d9e463a4d3ab2a24ca4b94786@haskell.org> Message-ID: <061.60287806f99c5164da0627b872651750@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:26 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:26 -0000

#7685: :script command does not resolve ~ -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"ddc79b229d58c1bed8ae19b955b491436e015e96/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ddc79b229d58c1bed8ae19b955b491436e015e96" GHCi: Expand ~ in :script command Fixes: #7685 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7685#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 09:04:44 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 09:04:44 -0000 Subject: [GHC] #8276: Building Haddock documentation panics with perf build on x86_64 Linux In-Reply-To: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> References: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> Message-ID: <063.d03e29f85eeefff71bc3aee5af8e56ed@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:26 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:26 -0000

#8276: Building Haddock documentation panics with perf build on x86_64 Linux ---------------------------------------+---------------------------------- Reporter: jstolarek | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Documentation | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by thoughtpolice): Simon, this looks good to me. I'll merge this into Haddock and remove the `{save,restore}StaticFlagGlobals` code from GHC shortly. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8276#comment:34 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 09:05:37 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 09:05:37 -0000 Subject: [GHC] #8276: Building Haddock documentation panics with perf build on x86_64 Linux In-Reply-To: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> References: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> Message-ID: <063.2ae739a266819fde3a9456c30173fc37@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:26 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:26 -0000

#8276: Building Haddock documentation panics with perf build on x86_64 Linux ---------------------------------------+---------------------------------- Reporter: jstolarek | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Documentation | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by thoughtpolice): And I double checked Cabal - none of the remaining static flags are passed to GHC. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8276#comment:35 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 09:54:28 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 09:54:28 -0000 Subject: [GHC] #8426: one-shot compilation + TH doesn't see instances that is seen in batch mode Message-ID: <044.d5acc485a28c44206c1ed91a697769e3@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:26 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:26 -0000

#8426: one-shot compilation + TH doesn't see instances that is seen in batch mode ----------------------------------------------+---------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Other Blocked By: | Test Case: Related Tickets: #7867 | Blocking: ----------------------------------------------+---------------------------- Haskell prime and Haskell98 both states that instances are always seen if there is any chain of imports leading from the current module to the instance. http://darcs.haskell.org/haskell-prime-report/report/haskell-report- html/modules.html#import-instances The ghc manual contains a discussion why this specification is too performance heavy to n?ively implement and contains the definition of orphanness and an algorithm to reproduce the specification with better performance. http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/separate- compilation.html#orphan-modules Unfortunately this cleverness breaks template haskell. Namely, if: - `Class.hs` contains a class, - `NonOrphan.hs` contains a data that implements the class, - `Importer.hs` just imports `NonOrphan.hs`, - `Main.hs` imports `Importer.hs`, - `Main.hs` reifies the class; then: - one-shot compilation's reify doesn't see the instance, - batch compilation's reify sees the instance. This ambiguity is shown in the attached tgz. Furthermore if `NonOrphan.hs` is in a separate package, then of course even batch compilation mode wouldn't reify the instance correctly. In that case there is no disambiguity between one-shot and batch, simply both is missing the info. I propose to solve this by enforcing a loading of all the interface files for every import transitively for the current module, when we meet an open type family or class reification request in template haskell's reify handler in `TcSplice.hs`. So I propose to keep the optimization of orphan instances and use it 99.9% of the time. We would only ever go on the quest of reading interface files for every import transitively when the user tries to reify something where we have to return an instance list. This means that TH compilations that reify types will get a little bit slower in exchange of being correct and unambiguous. Compilation time in cases when TH reification is not used will not change. I volunteer to prepare the patch, but would like to hear others first. So, any opinions, alternative ideas? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8426 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 09:56:36 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 09:56:36 -0000 Subject: [GHC] #8408: Ambiguity in TH reify based on compilation method In-Reply-To: <044.3017443dfaccd9131ca33cba42500d5d@haskell.org> References: <044.3017443dfaccd9131ca33cba42500d5d@haskell.org> Message-ID: <059.e29586270d827904aab7e463ffb405d3@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:27 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:27 -0000

From ghc-devs at haskell.org Wed Oct 9 09:57:27 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 09:57:27 -0000 Subject: [GHC] #8426: one-shot compilation + TH doesn't see instances

#8408: Ambiguity in TH reify based on compilation method -------------------------------------+------------------------------------ Reporter: errge | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by errge): * status: new => closed * resolution: => duplicate Comment: Now I understand this issue better than before and prepared another bug: #8426. That contains a more clear explanation of the issue and a proposal to fix it. Therefore I'm closing this one as a duplicate. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8408#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler that is seen in batch mode In-Reply-To: <044.d5acc485a28c44206c1ed91a697769e3@haskell.org> References: <044.d5acc485a28c44206c1ed91a697769e3@haskell.org> Message-ID: <059.d9422a3be74fb1154369ad0c9ef44080@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:27 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:27 -0000 #8426: one-shot compilation + TH doesn't see instances that is seen in batch mode ----------------------------+---------------------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.7 Template Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less than a day) Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: #7867 Test Case: | Blocking: | ----------------------------+---------------------------------------------- Changes (by errge): * version: 7.6.3 => 7.7 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8426#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 11:50:02 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 11:50:02 -0000 Subject: [GHC] #8276: Building Haddock documentation panics with perf build on x86_64 Linux In-Reply-To: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> References: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> Message-ID: <063.bb070740cd2a94017aff553ac4a29363@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:27 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:27 -0000

#8276: Building Haddock documentation panics with perf build on x86_64 Linux ---------------------------------------+---------------------------------- Reporter: jstolarek | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Documentation | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by thoughtpolice): hrrrrrrrrrrrrrgh. OK, so this patch mostly works but there's a problem; several libraries use `-fcpr-off` which is a !StaticFlag, meaning when it's passed to Haddock things mess up. Thinking about it, there are two other cases this could happen: * `-fno-state-hack` * `-fno-opt-coercion` To change this !StaticFlag would literally upset hundreds upon hundreds of call sites, and require substantial refactoring as it would introduce boot files and recursive dependencies across the frontend. Basically, the same thing I mentioned before. SimonH, me and Edsko are also a bit confused on how this randomly popped up out of nowhere as well. Perhaps Christiaan's patch is the way to go, but I don't like keeping code like this around since it seems broke. I'm not sure we have much of an option, however, until I get around to removing the remaining !StaticFlags. Which will take a while. Alternatively, we can still remove all this code, and simply special-case Haddock and !DocTest to totally ignore these flags and just not pass them to GHC. While they ''do'' affect how the optimizers work, I'm do not believe this could affect either Haddock or !DocTest in most situations. Thoughts? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8276#comment:36 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 12:02:21 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 12:02:21 -0000 Subject: [GHC] #8139: ghc 7.6.3 and ghc HEAD fails to build on OS X 10.9 In-Reply-To: <052.92009bd3b6836bd26916c16cd983224b@haskell.org> References: <052.92009bd3b6836bd26916c16cd983224b@haskell.org> Message-ID: <067.836b2b72d20a4718557942b2e4c97575@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:27 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:27 -0000

#8139: ghc 7.6.3 and ghc HEAD fails to build on OS X 10.9 -------------------------------------+------------------------------------- Reporter: darinmorrison | Owner: darinmorrison Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by darinmorrison): * status: new => patch -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8139#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 12:19:29 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 12:19:29 -0000 Subject: [GHC] #8139: ghc 7.6.3 and ghc HEAD fails to build on OS X 10.9 In-Reply-To: <052.92009bd3b6836bd26916c16cd983224b@haskell.org> References: <052.92009bd3b6836bd26916c16cd983224b@haskell.org> Message-ID: <067.6412a3d56842d2b88b22ac691c99cab2@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:27 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:27 -0000

#8139: ghc 7.6.3 and ghc HEAD fails to build on OS X 10.9 -------------------------------------+------------------------------------- Reporter: darinmorrison | Owner: darinmorrison Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by darinmorrison): Just realized these are patches against the 7.6.3-release branch. They probably still apply cleanly to HEAD but I'll go ahead and double check later tonight and upload fixed versions if necessary. Sorry about that? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8139#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 12:34:17 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 12:34:17 -0000 Subject: [GHC] #8139: ghc 7.6.3 and ghc HEAD fails to build on OS X 10.9 In-Reply-To: <052.92009bd3b6836bd26916c16cd983224b@haskell.org> References: <052.92009bd3b6836bd26916c16cd983224b@haskell.org> Message-ID: <067.f0949cc1a8385733f5eacda4c69010c4@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:27 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:27 -0000

#8139: ghc 7.6.3 and ghc HEAD fails to build on OS X 10.9 -------------------------------------+------------------------------------- Reporter: darinmorrison | Owner: darinmorrison Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by darinmorrison): I updated the patches for HEAD but forgot to click "overwrite" for one of them. Ignore the ?8139.2.patch. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8139#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 12:36:04 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 12:36:04 -0000 Subject: [GHC] #8418: [patch] comments outdated In-Reply-To: <044.7e7191ded062fdfcc30c9668e68cf5e6@haskell.org> References: <044.7e7191ded062fdfcc30c9668e68cf5e6@haskell.org> Message-ID: <059.fe5d446c9d20ed6ef51df0ec2e428ca2@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:27 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:27 -0000

#8418: [patch] comments outdated -------------------------------+------------------------------------------- Reporter: errge | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by Austin Seipp ): In [changeset:"7fad107f61313f11cb0b40e0310ede4c119467fd/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7fad107f61313f11cb0b40e0310ede4c119467fd" Clean up some outdated comments (#8418) Authored-by: Gergely Risko <gergely at risko.hu> Signed-off-by: Austin Seipp <austin at well-typed.com> }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8418#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 12:37:02 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 12:37:02 -0000 Subject: [GHC] #8223: System.Posix.User fails to build on systems without get{gr, pw}nam_r In-Reply-To: <047.dc9473608360c135fd8ae7543418ef42@haskell.org> References: <047.dc9473608360c135fd8ae7543418ef42@haskell.org> Message-ID: <062.2591a4692a81bd227e9b1872f37beae1@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:27 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:27 -0000

#8223: System.Posix.User fails to build on systems without get{gr,pw}nam_r ----------------------------------------+--------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/unix | Version: 7.7 Resolution: fixed | Keywords: Operating System: Other | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8223#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 12:37:41 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 12:37:41 -0000 Subject: [GHC] #8418: [patch] comments outdated In-Reply-To: <044.7e7191ded062fdfcc30c9668e68cf5e6@haskell.org> References: <044.7e7191ded062fdfcc30c9668e68cf5e6@haskell.org> Message-ID: <059.91b8fae06c583318faf53d8281d0d8a5@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:27 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:27 -0000

#8418: [patch] comments outdated -------------------------------+------------------------------------------- Reporter: errge | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8418#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 13:17:28 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 13:17:28 -0000 Subject: [GHC] #8424: quasi-quotes have carriage returns on Windows In-Reply-To: <048.22a0e52e93667b75ca5f688b556e6150@haskell.org> References: <048.22a0e52e93667b75ca5f688b556e6150@haskell.org> Message-ID: <063.990dcf1c69fa5044909e07a494a53152@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:28 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:28 -0000

#8424: quasi-quotes have carriage returns on Windows -------------------------------------+------------------------------------ Reporter: GregWeber | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by GregWeber): yes, that is an equivalent example source file. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8424#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 14:02:35 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 14:02:35 -0000 Subject: [GHC] #4385: Type-level natural numbers In-Reply-To: <047.cc0a64c6c51b4985aaaaf093ec247386@haskell.org> References: <047.cc0a64c6c51b4985aaaaf093ec247386@haskell.org> Message-ID: <062.109dedb52100a5ddd7e8633b33fb87eb@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:28 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:28 -0000

#4385: Type-level natural numbers --------------------------------------------+------------------------------ Reporter: diatchki | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler (Type checker) | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by ghorn): * cc: gregmainland@? (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/4385#comment:65 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 14:09:29 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 14:09:29 -0000 Subject: [GHC] #8276: Building Haddock documentation panics with perf build on x86_64 Linux In-Reply-To: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> References: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> Message-ID: <063.de444b3bb9c79c8d800c71123c97004a@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:28 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:28 -0000

#8276: Building Haddock documentation panics with perf build on x86_64 Linux ---------------------------------------+---------------------------------- Reporter: jstolarek | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Documentation | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by SimonHengel): If we can add a function {{{ discardStaticFlags :: [String] -> [String] }}} that removes static (including any arguments given to them, if any, not sure if there are static flags that take arguments) to the GHC API, then I'm fine with ignoring them in Haddock/Doctest. Medium term it would still be nice to get rid of static flags completely, of course. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8276#comment:37 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 14:14:35 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 14:14:35 -0000 Subject: [GHC] #8276: Building Haddock documentation panics with perf build on x86_64 Linux In-Reply-To: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> References: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> Message-ID: <063.2dd09307432281789244d9799ac91525@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:28 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:28 -0000

#8276: Building Haddock documentation panics with perf build on x86_64 Linux ---------------------------------------+---------------------------------- Reporter: jstolarek | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Documentation | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by thoughtpolice): Yes, I can do this. And I agree (with you and Ian) that removing all the StaticFlags would be preferrable - it's just unfortunately a very large change to remove the last of them. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8276#comment:38 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 14:51:12 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 14:51:12 -0000 Subject: [GHC] #8423: contraint solver doesn't reduce reducible closed type family expressions (even with undecidable instances!) In-Reply-To: <045.e519cd37d8a4b1c71c71d8593787d92e@haskell.org> References: <045.e519cd37d8a4b1c71c71d8593787d92e@haskell.org> Message-ID: <060.d6cf5a8600411aae921e3691a686c0cc@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:28 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:28 -0000

#8423: contraint solver doesn't reduce reducible closed type family expressions (even with undecidable instances!) --------------------------------------------+------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #4259 --------------------------------------------+------------------------------ Comment (by goldfire): If you just want a way to check things, please see [https://gist.github.com/goldfirere/6902431 here]. The key step is that you do in fact have to write proofs! These proofs may, sadly, have runtime significance. But, from the optimization results in the "Deferred type errors" [http://research.microsoft.com/en- us/um/people/simonpj/papers/ext-f/icfp12.pdf paper] lead me to wonder if these runtime traces are optimized away. (I haven't checked -- doing so is beyond the scope of my morning Haskell stretches.) I did check, though, that the inliner will remove calls to `gcoerce` and make `go` properly tail-recursive (ignoring the type-cast, which I know is removed at runtime). Thanks for posting this! It's made me realize that `gcoerce` from that example should probably be in the Data.Type.Equality module anyway. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8423#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 15:50:33 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 15:50:33 -0000 Subject: [GHC] #8427: GHC accepts invalid program because of EPS poisoning Message-ID: <044.8d7cfe02b3e4ed540e00001a8151e1c6@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:28 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:28 -0000

#8427: GHC accepts invalid program because of EPS poisoning -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHC accepts Difficulty: Moderate (less | invalid program than a day) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Assume the following setup: - compiling in batch mode (`--make`), - package klassz, module Class contains the class "Class a" and the data "Data", - package klassz, module A contains an (orphan) instance "Class Data", - package main, module AImporter just imports A, - package main, module B imports only Class, but uses the instance (invalidly); then - if package main, module Main imports B, later imports AImporter; then it compiles; - if package main, module Main imports AImporter, later imports B, then it doesn't compile. The attached tgz contains this setup. `diff -u main-docompile main- nocompile` shows that the only difference between the two main directories is the order of import statements. The language definitely doesn't accept compilation success to depend on import ordering, therefore this is a bug. My current understanding is that the issue is that this code should never compile, both mains should be rejected, since module B imports only the class, but not the instance. The issue is that the EPS is only ever increased, never decreased between compilation of different modules in a single batch compilation. This na?ve approach causes the instances to be loaded and then never unloaded, so it can be magically found when compiling the invalid B module. The current code can be found in [[GhcFile(compiler/iface/LoadIface.hs)]] line 280. I propose to instead of always loading ifaces into the EPS directly, introduce a proper cache for interfaces, that contains parsed up interface data in a `ModuleEnv`. Then we can start up with an empty EPS at the beginning of the compilation of every unit and quickly merge info from this cache. I guess the majority of time is the file reading IO and the parsing, not the merging of multiple interface files together. I also think that these kind of issues will get more and more prominent as people start to use parallel cabal and ghc, because if compilation of the attached example program is randomly parallelized, then in some cases it will build, some cases it won't. Any opinions, alternative fix ideas? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8427 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 15:57:17 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 15:57:17 -0000 Subject: [GHC] #8428: Incorrect type formatting in error messages Message-ID: <043.9d3de32b4124b73120648c4e309fe6a1@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:28 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:28 -0000

#8428: Incorrect type formatting in error messages ------------------------------------+------------------------------------- Reporter: klao | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I've been trying to write a type signature to something completely analogous to `runST . runIdentityT`, and failing miserably for a long time. At some point I had the following: {{{#!haskell {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ImpredicativeTypes #-} module Test where import Control.Monad.ST import Control.Monad.Trans.Identity runIdST :: IdentityT (forall s. ST s) a -> a runIdST = runST . runIdentityT }}} You can see that I was very confused about `forall` here (probably still am), but what makes it much worse is the error message with which this fails: {{{ src/Test.hs:10:19: Couldn't match type `forall s. ST s a' with `forall s. ST s a' Expected type: IdentityT (forall s. ST s) a -> forall s. ST s a Actual type: IdentityT (forall s. ST s) a -> forall s. ST s a In the second argument of `(.)', namely `runIdentityT' In the expression: runST . runIdentityT In an equation for `runIdST': runIdST = runST . runIdentityT }}} It says it couldn't match `forall s. ST s a` with `forall s. ST s a`. What's up with that?! This has lead me to a long diversion. Finally, we found the right type for this function (and discovered that the problem is also in the `(.)`, which doesn't have the same special treatment as `($)`), and afterwards we realized, that types in the above error message ''are'' actually different. One is `(forall s. (ST s)) a`, and the other is `forall s. ((ST s) a)`. But they are presented in exactly the same way! The issue is in the `instance Outputable Type`, which has too simplistic precedence rules, I guess. Thanks to `@errge` for help with debugging this. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8428 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 15:59:09 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 15:59:09 -0000 Subject: [GHC] #8276: Building Haddock documentation panics with perf build on x86_64 Linux In-Reply-To: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> References: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> Message-ID: <063.dd172f43492b669e870807a8c2e809e1@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:28 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:28 -0000

#8276: Building Haddock documentation panics with perf build on x86_64 Linux ---------------------------------------+---------------------------------- Reporter: jstolarek | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Documentation | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by Austin Seipp ): In [changeset:"16c401137a0d2aa803a5806493889056538c2de4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="16c401137a0d2aa803a5806493889056538c2de4" Nuke {save,restore}StaticFlagGlobals. As discussed in #8276, this code was somewhat broken because while you could always revert the actual argument list, you can never revert the CAFs upon which they are based - so really this didn't buy you much. However, Haddock in particular expects to be able to parse GHC flags, including static flags, and used this code to do so. In its place, we instead have discardStaticFlags, which will safely remove any of the remaining 5 flags from a list of arguments. Haddock instead discards these, as they aren't related to anything it does anyway (mostly controlling debugging output and some basic optimizer phases.) This fixes #8276. In the future, we will eventually completely remove the remaining StaticFlags, removing the need for this fix. Unfortunately these changes will be quite invasive and require more time. Signed-off-by: Austin Seipp <austin at well-typed.com> }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8276#comment:39 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 16:00:24 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 16:00:24 -0000 Subject: [GHC] #8276: Building Haddock documentation panics with perf build on x86_64 Linux In-Reply-To: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> References: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> Message-ID: <063.18bcfd7168652b9bc19370394ee3038d@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:28 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:28 -0000

#8276: Building Haddock documentation panics with perf build on x86_64 Linux ---------------------------------------+---------------------------------- Reporter: jstolarek | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Documentation | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by thoughtpolice): Simon, I've done this. Would you please review https://github.com/ghc/haddock/commit/c6faeae064668125721b0d5e60f067f90c5389... - which is based on the patch you provided? It merely uses `discardStaticFlags` to remove the problematic flags before running GHC via the API. If it looks good, I think we can close this. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8276#comment:40 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 16:15:02 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 16:15:02 -0000 Subject: [GHC] #8276: Building Haddock documentation panics with perf build on x86_64 Linux In-Reply-To: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> References: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> Message-ID: <063.ed6e140ec52fce302691cd8fdd039bcb@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:29 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:29 -0000

#8276: Building Haddock documentation panics with perf build on x86_64 Linux ---------------------------------------+---------------------------------- Reporter: jstolarek | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Documentation | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by SimonHengel): Looks good to me. :) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8276#comment:41 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 16:20:50 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 16:20:50 -0000 Subject: [GHC] #8276: Building Haddock documentation panics with perf build on x86_64 Linux In-Reply-To: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> References: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> Message-ID: <063.ebb40e9847b63e01374397888122ec62@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:29 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:29 -0000

#8276: Building Haddock documentation panics with perf build on x86_64 Linux ---------------------------------------+---------------------------------- Reporter: jstolarek | Owner: thoughtpolice Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Documentation | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: Excellent! Thank you for being so cooperative Simon! Everyone else, this should be Fixed for Good Now. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8276#comment:42 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 17:42:13 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 17:42:13 -0000 Subject: [GHC] #7867: Allow template-haskell to communicate with itself between compilation units through the interface file In-Reply-To: <044.7393523543fe94ac1b36b652004b6974@haskell.org> References: <044.7393523543fe94ac1b36b652004b6974@haskell.org> Message-ID: <059.09e4e78967d09b26cb387f7d7bc60772@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:29 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:29 -0000

From ghc-devs at haskell.org Wed Oct 9 17:42:39 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 17:42:39 -0000 Subject: [GHC] #8426: one-shot compilation + TH doesn't see instances

#7867: Allow template-haskell to communicate with itself between compilation units through the interface file --------------------------+------------------------------------------------ Reporter: errge | Owner: Type: | Status: patch feature request | Milestone: 7.8.1 Priority: | Version: 7.6.3 normal | Keywords: Component: | Architecture: Unknown/Multiple Template Haskell | Difficulty: Easy (less than 1 hour) Resolution: | Blocked By: 3725, 8337, 8340, 8397, 8398 Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | --------------------------+------------------------------------------------ Comment (by errge): The wiki page is ready. http://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Annotations All comments are welcome. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7867#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler that is seen in batch mode In-Reply-To: <044.d5acc485a28c44206c1ed91a697769e3@haskell.org> References: <044.d5acc485a28c44206c1ed91a697769e3@haskell.org> Message-ID: <059.ca2c964288fc767ca7225c2138250f74@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:29 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:29 -0000 #8426: one-shot compilation + TH doesn't see instances that is seen in batch mode ----------------------------+---------------------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.7 Template Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less than a day) Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: #7867 Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by errge): For related work, see also the discussion in: http://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Annotations -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8426#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 17:49:23 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 17:49:23 -0000 Subject: [GHC] #8428: Incorrect type formatting in error messages In-Reply-To: <043.9d3de32b4124b73120648c4e309fe6a1@haskell.org> References: <043.9d3de32b4124b73120648c4e309fe6a1@haskell.org> Message-ID: <058.ee914039d9b5c42bb616debdab22979e@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:29 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:29 -0000

#8428: Incorrect type formatting in error messages -------------------------------+------------------------------------------- Reporter: klao | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by klao): * status: new => patch * difficulty: Unknown => Easy (less than 1 hour) Comment: The more I look at the code in `TypeRep.lhs`, the more it looks like a simple omission. I attach a trivial patch that fixes the issue (and doesn't seem to break anything else; at least not according to the test suite). Note that I also removed a spurious `\end{code}` label, which broke emacs' literate Haskell syntax highlighting on this file. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8428#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 19:00:29 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 19:00:29 -0000 Subject: [GHC] #8425: ghc-7.6.3: crossmodule inline leads to buggy code (-O2) In-Reply-To: <045.a29452ea9fbac42eef37cbddc5ab6d06@haskell.org> References: <045.a29452ea9fbac42eef37cbddc5ab6d06@haskell.org> Message-ID: <060.8e16cd678fded0d4c6f7016d3b43a53f@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:29 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:29 -0000

#8425: ghc-7.6.3: crossmodule inline leads to buggy code (-O2) -------------------------------------+---------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by carter): I believe this is a known issue in http://ghc.haskell.org/trac/ghc/ticket/5550 and http://ghc.haskell.org/trac/ghc/ticket/7944 ? could you try compiling the code with HEAD and see if the error is still there? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8425#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 19:02:41 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 19:02:41 -0000 Subject: [GHC] #8428: Incorrect type formatting in error messages In-Reply-To: <043.9d3de32b4124b73120648c4e309fe6a1@haskell.org> References: <043.9d3de32b4124b73120648c4e309fe6a1@haskell.org> Message-ID: <058.afd0f0557d11ef04c5318b769ea0a394@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:29 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:29 -0000

#8428: Incorrect type formatting in error messages -------------------------------+------------------------------------------- Reporter: klao | Owner: monoidal Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by monoidal): * owner: => monoidal -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8428#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 19:45:43 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 19:45:43 -0000 Subject: [GHC] #8423: contraint solver doesn't reduce reducible closed type family expressions (even with undecidable instances!) In-Reply-To: <045.e519cd37d8a4b1c71c71d8593787d92e@haskell.org> References: <045.e519cd37d8a4b1c71c71d8593787d92e@haskell.org> Message-ID: <060.84f4c823b5a94980161f9fbaddb6d462@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:29 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:29 -0000

#8423: contraint solver doesn't reduce reducible closed type family expressions (even with undecidable instances!) --------------------------------------------+------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #4259 --------------------------------------------+------------------------------ Comment (by carter): thanks! this is great! Would I want to compare the core? (or just use criterion to benchmark?). I'll add that to my infinite todo list. This example seems to work only in ghc 7.8, how would i adapt those ideas to work on 7.6? (can I even?) that said, having more examples like this about how to prove things in haskell is probably a good idea! Also, figuring out how to erase such proofs as much as possible also would likely be worth while. I'm happy to help contribute a few braincells to chewing on that post 7.8 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8423#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 20:10:21 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 20:10:21 -0000 Subject: [GHC] #8428: Incorrect type formatting in error messages In-Reply-To: <043.9d3de32b4124b73120648c4e309fe6a1@haskell.org> References: <043.9d3de32b4124b73120648c4e309fe6a1@haskell.org> Message-ID: <058.da079abcb89e25b7cca65da9cd1f3c5d@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:29 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:29 -0000

#8428: Incorrect type formatting in error messages -------------------------------+------------------------------------------- Reporter: klao | Owner: monoidal Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"a83652ed4aee321063c17df1ad8560712b33103a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a83652ed4aee321063c17df1ad8560712b33103a" Show parentheses when printing type (forall x. T1) T2 (#8428) Patch by klao }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8428#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 20:11:37 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 20:11:37 -0000 Subject: [GHC] #8428: Incorrect type formatting in error messages In-Reply-To: <043.9d3de32b4124b73120648c4e309fe6a1@haskell.org> References: <043.9d3de32b4124b73120648c4e309fe6a1@haskell.org> Message-ID: <058.eebcda42f0241555db7a7ea74a2abc23@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:29 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:29 -0000

#8428: Incorrect type formatting in error messages -------------------------------+------------------------------------------- Reporter: klao | Owner: monoidal Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"1420081d39aacaa6c8acfc0f31811a4d6c2d1c5c/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="1420081d39aacaa6c8acfc0f31811a4d6c2d1c5c" Test #8428 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8428#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 20:12:46 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 20:12:46 -0000 Subject: [GHC] #8428: Incorrect type formatting in error messages In-Reply-To: <043.9d3de32b4124b73120648c4e309fe6a1@haskell.org> References: <043.9d3de32b4124b73120648c4e309fe6a1@haskell.org> Message-ID: <058.40263dde7942bc72e4913e4d9363caa8@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:30 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:30 -0000

#8428: Incorrect type formatting in error messages -------------------------------------+------------------------------------- Reporter: klao | Owner: monoidal Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Easy (less than 1 Test Case: | hour) typecheck/should_fail/T8428 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => closed * testcase: => typecheck/should_fail/T8428 * resolution: => fixed Comment: Looks good, I've pushed it. Thanks for the patch. The type `(forall s. ST s)` should be rejected as a kind error, because under the forall there should be a type of kind *, not * -> * or similar. However, we currently do not detect this (#8388). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8428#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 21:19:07 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 21:19:07 -0000 Subject: [GHC] #8425: ghc-7.6.3: crossmodule inline leads to buggy code (-O2) In-Reply-To: <045.a29452ea9fbac42eef37cbddc5ab6d06@haskell.org> References: <045.a29452ea9fbac42eef37cbddc5ab6d06@haskell.org> Message-ID: <060.cd038dc1540481136645d06a18e4c7fd@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:30 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:30 -0000

#8425: ghc-7.6.3: crossmodule inline leads to buggy code (-O2) -------------------------------------+---------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by monoidal): That's a different ticket. I can reproduce the "Error in array index" in 7.6, but in HEAD it works fine. I will close the ticket soon, but leave some time in case someone more experienced knows what's going on. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8425#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Wed Oct 9 21:26:55 2013 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Oct 2013 21:26:55 -0000 Subject: [GHC] #8425: ghc-7.6.3: crossmodule inline leads to buggy code (-O2) In-Reply-To: <045.a29452ea9fbac42eef37cbddc5ab6d06@haskell.org> References: <045.a29452ea9fbac42eef37cbddc5ab6d06@haskell.org> Message-ID: <060.97cff689d81d941ad417f7426cc21f59@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:30 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:30 -0000

I believe this is a known issue in http://ghc.haskell.org/trac/ghc/ticket/5550 and http://ghc.haskell.org/trac/ghc/ticket/7944 ?

could you try compiling the code with HEAD and see if the error is still

#8425: ghc-7.6.3: crossmodule inline leads to buggy code (-O2) -------------------------------------+---------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by slyfox): Replying to [comment:1 carter]: there? Yeah, head works: # ./run_test.bash ... ,("Project version","7.7.20131009") ,("Booter version","7.6.3") ,("Stage","2") ,("Build platform","x86_64-unknown-linux") ,("Host platform","x86_64-unknown-linux") ,("Target platform","x86_64-unknown-linux") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("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") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/var/tmp/portage/dev- lang/ghc-9999/work/ghc-9999/inplace/lib") ,("Global Package DB","/var/tmp/portage/dev- lang/ghc-9999/work/ghc-9999/inplace/lib/package.conf.d") ] RUN good [1 of 2] Compiling Susp ( good/Susp.hs, good/Susp.o ) [2 of 2] Compiling Main ( good/main.hs, good/main.o ) Linking good/main ... (fromList [(array (0,0) [(0,42)],0)],0) RUN bad [1 of 3] Compiling BuggyOpt ( bad/BuggyOpt.hs, bad/BuggyOpt.o ) [2 of 3] Compiling Susp ( bad/Susp.hs, bad/Susp.o ) [3 of 3] Compiling Main ( bad/main.hs, bad/main.o ) Linking bad/main ... (fromList [(array (0,0) [(0,42)],0)],0) But why are those bugs related to this issue? AFAIU they are compile-time issues. May I ask you to point to related commitspossibly fixing this? And what workaround would you suggest for this particular code? I'm using {-# NOINLINE #-} in random places inside miscompiled function. Thanks! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8425#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 10 02:47:47 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Oct 2013 02:47:47 -0000 Subject: [GHC] #8320: Build fails due to Haddock error in ghc-prim:GHC.Types In-Reply-To: <044.d03a5005166332b97ad3b025d8d241c6@haskell.org> References: <044.d03a5005166332b97ad3b025d8d241c6@haskell.org> Message-ID: <059.6105a7086f3c021c89e4e0d413b8ab67@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:30 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:30 -0000

#8320: Build fails due to Haddock error in ghc-prim:GHC.Types ----------------------------------------+--------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by kazu-yamamoto): Even after #8276 is fixed, this problem still exists. I met this problem on 32bit Linux and FreeBSD today. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8320#comment:26 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 10 08:27:31 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Oct 2013 08:27:31 -0000 Subject: [GHC] #8429: GHC.Base.{breakpoint, breakpointCond} do nothing Message-ID: <045.4c9eb90270eb503495dbeb412abc60e7@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:30 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:30 -0000

#8429: GHC.Base.{breakpoint, breakpointCond} do nothing ------------------------------------+------------------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 1377 | ------------------------------------+------------------------------------- The `GHC.Exts` module exports functions [[http://hackage.haskell.org/package/base-4.6.0.1/docs/GHC- Exts.html#g:6|breakpoint and breakpointCond]]. Right now they are no-ops, but apparently at some point in the past could be used to set breakpoints programmatically. From my reading of the source code, this feature was removed (either accidentally or on purpose) when the implementation of breakpoints [[changeset:cdce647711c0f46f5799b24de087622cb77e647f/ghc|was reworked]]. Relevant commits: * 31751ccacc24ebe5d15a0af84b10dc612d455440 * 3a99fa889bdff0c86df20cb18c71d30e30a79b43 * cdce647711c0f46f5799b24de087622cb77e647f Initially reported [http://stackoverflow.com/questions/19283911/how-do-i -use-ghc-exts-breakpoint here]. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8429 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 10 08:29:57 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Oct 2013 08:29:57 -0000 Subject: [GHC] #8429: GHC.Base.{breakpoint, breakpointCond} do nothing In-Reply-To: <045.4c9eb90270eb503495dbeb412abc60e7@haskell.org> References: <045.4c9eb90270eb503495dbeb412abc60e7@haskell.org> Message-ID: <060.792e2521b9219dcbf420ff8c59a4bfc9@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:30 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:30 -0000

#8429: GHC.Base.{breakpoint, breakpointCond} do nothing -------------------------------------+------------------------------------ Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 1377 -------------------------------------+------------------------------------ Comment (by refold): Replying to [ticket:8429 refold]:

Relevant commits: * 31751ccacc24ebe5d15a0af84b10dc612d455440 * 3a99fa889bdff0c86df20cb18c71d30e30a79b43 * cdce647711c0f46f5799b24de087622cb77e647f

Grep for `breakpointName`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8429#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 10 09:15:23 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Oct 2013 09:15:23 -0000 Subject: [GHC] #8429: GHC.Base.{breakpoint, breakpointCond} do nothing In-Reply-To: <045.4c9eb90270eb503495dbeb412abc60e7@haskell.org> References: <045.4c9eb90270eb503495dbeb412abc60e7@haskell.org> Message-ID: <060.8db3a5f2b0ad3b0c552540a7e8bf3dd8@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:30 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:30 -0000

#8429: GHC.Base.{breakpoint, breakpointCond} do nothing -------------------------------------+------------------------------------ Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 1377 -------------------------------------+------------------------------------ Changes (by simonpj): * cc: simonmar (added) Comment: Adding Simon M in cc, who was involved in adding breakpoint support, and committed the last of the three patches above with title "Re-working of the breakpoint support". Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8429#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 10 09:46:19 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Oct 2013 09:46:19 -0000 Subject: [GHC] #8430: Literate haskell accepts spurious \end{code} lines Message-ID: <044.7242a970e3463fe0811ca55e762567c5@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:30 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:30 -0000

#8430: Literate haskell accepts spurious \end{code} lines -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHC accepts Difficulty: Easy (less than 1 | invalid program hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- In #8428 klao removed a spurious \end{code} from `TypeRep.lhs`. This made it clear that GHC has accepts spurious \end{code} lines in literate haskell code. This patch fixes the literate haskell preprocessor to issue an error in this case. Interestingly though, after this change nothing breaks except for klao's already merged patch, so this issue was not found in other .lhs files through GHC. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8430 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 10 10:00:33 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Oct 2013 10:00:33 -0000 Subject: [GHC] #8428: Incorrect type formatting in error messages In-Reply-To: <043.9d3de32b4124b73120648c4e309fe6a1@haskell.org> References: <043.9d3de32b4124b73120648c4e309fe6a1@haskell.org> Message-ID: <058.5ca223fb78671be921f0d1fb2fa597e4@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:31 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:31 -0000

#8428: Incorrect type formatting in error messages -------------------------------------+------------------------------------- Reporter: klao | Owner: monoidal Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Easy (less than 1 Test Case: | hour) typecheck/should_fail/T8428 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by simonpj): Thank you. Absolutely right. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8428#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 10 10:05:19 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Oct 2013 10:05:19 -0000 Subject: [GHC] #8430: Literate haskell accepts spurious \end{code} lines In-Reply-To: <044.7242a970e3463fe0811ca55e762567c5@haskell.org> References: <044.7242a970e3463fe0811ca55e762567c5@haskell.org> Message-ID: <059.fcd65ef043c7201ca7f0930220d6a84e@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:31 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:31 -0000

#8430: Literate haskell accepts spurious \end{code} lines -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHC accepts | Difficulty: Easy (less than 1 invalid program | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => patch Comment: OK with me. Thanks. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8430#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 10 10:55:33 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Oct 2013 10:55:33 -0000 Subject: [GHC] #8431: ghci freezes in multiline when passed a closing paren Message-ID: <044.fc0b13a44f809091529a93c8522bae49@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:31 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:31 -0000

#8431: ghci freezes in multiline when passed a closing paren -------------------------------------------+------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: -------------------------------------------+------------------------------- {{{ Prelude> :set +m Prelude> ) }}} Never returns. Patch attached. John's code was buggy and reachable, apparently. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8431 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 10 10:55:56 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Oct 2013 10:55:56 -0000 Subject: [GHC] #8431: ghci freezes in multiline when passed a closing paren In-Reply-To: <044.fc0b13a44f809091529a93c8522bae49@haskell.org> References: <044.fc0b13a44f809091529a93c8522bae49@haskell.org> Message-ID: <059.4352716777b71e20f89d08a2b075a250@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:31 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:31 -0000

#8431: ghci freezes in multiline when passed a closing paren -------------------------------+------------------------------------------- Reporter: errge | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------+------------------------------------------- Changes (by errge): * status: new => patch -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8431#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 10 10:56:20 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Oct 2013 10:56:20 -0000 Subject: [GHC] #8431: ghci freezes in multiline when passed a closing paren In-Reply-To: <044.fc0b13a44f809091529a93c8522bae49@haskell.org> References: <044.fc0b13a44f809091529a93c8522bae49@haskell.org> Message-ID: <059.7634de68e3b0c596ac8855194eca026f@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:31 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:31 -0000

#8431: ghci freezes in multiline when passed a closing paren -------------------------------+------------------------------------------- Reporter: errge | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------+------------------------------------------- Comment (by errge): Thanks goes to klao for helping me while debugging this. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8431#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 10 11:10:49 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Oct 2013 11:10:49 -0000 Subject: [GHC] #8431: ghci freezes in multiline when passed a closing paren In-Reply-To: <044.fc0b13a44f809091529a93c8522bae49@haskell.org> References: <044.fc0b13a44f809091529a93c8522bae49@haskell.org> Message-ID: <059.aebeefbebf4f69be9ee23a52d1d6bc37@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:31 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:31 -0000

#8431: ghci freezes in multiline when passed a closing paren -------------------------------+------------------------------------------- Reporter: errge | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------+------------------------------------------- Comment (by hvr): Can this bug also be triggered via ordinary compilation by enabling prime:AlternativeLayoutRule? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8431#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 10 12:55:43 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Oct 2013 12:55:43 -0000 Subject: [GHC] #8431: ghci freezes in multiline when passed a closing paren In-Reply-To: <044.fc0b13a44f809091529a93c8522bae49@haskell.org> References: <044.fc0b13a44f809091529a93c8522bae49@haskell.org> Message-ID: <059.5cfc04a22df46835cf882066c51f0190@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:32 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:32 -0000

#8431: ghci freezes in multiline when passed a closing paren -------------------------------+------------------------------------------- Reporter: errge | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------+------------------------------------------- Comment (by errge): I don't know what is AlternativeLayoutRule and I couldn't find any description of it. It's not documented in the manual and there are no examples on the linked wiki page or in the mailing list archives. The patch replaces a bottom with an empty list. So it's certainly an improvement :) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8431#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 10 16:18:56 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Oct 2013 16:18:56 -0000 Subject: [GHC] #8423: contraint solver doesn't reduce reducible closed type family expressions (even with undecidable instances!) In-Reply-To: <045.e519cd37d8a4b1c71c71d8593787d92e@haskell.org> References: <045.e519cd37d8a4b1c71c71d8593787d92e@haskell.org> Message-ID: <060.72952c5fe64277403475e74bb947c487@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:32 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:32 -0000

#8423: contraint solver doesn't reduce reducible closed type family expressions (even with undecidable instances!) --------------------------------------------+------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #4259 --------------------------------------------+------------------------------ Comment (by goldfire): This should work just fine in 7.6. Just change the closed type family `(+)` to be an open one. Everything else should just work. I've update [https://gist.github.com/goldfirere/6902431#file-shape-7-6-hs the gist] with a 7.6-compatible version. (I also had to inline a few definitions that aren't available in the 7.6 libraries.) Examining the core won't work, because even core needs the proofs to type- check! You might be able to examine something after core, but GHC's behavior after it's done with core is black magic to me. You might have to benchmark it. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8423#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 10 16:54:21 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Oct 2013 16:54:21 -0000 Subject: [GHC] #8421: ghc build failure with template haskell on ghc head In-Reply-To: <045.ea1628dce7af519cd36fc44039de3371@haskell.org> References: <045.ea1628dce7af519cd36fc44039de3371@haskell.org> Message-ID: <060.aea970d6ac90d7cda5828301d79a172e@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:32 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:32 -0000

#8421: ghc build failure with template haskell on ghc head ----------------------------------------+---------------------------------- Reporter: schell | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: invalid | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: I think it's 99% likely that parcs is right, so I'll close this. Re-open if wrong. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8421#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 10 16:59:19 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Oct 2013 16:59:19 -0000 Subject: [GHC] #8421: ghc build failure with template haskell on ghc head In-Reply-To: <045.ea1628dce7af519cd36fc44039de3371@haskell.org> References: <045.ea1628dce7af519cd36fc44039de3371@haskell.org> Message-ID: <060.7b09ad5f0ba987cbb35de7f46a440fd2@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:32 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:32 -0000

#8421: ghc build failure with template haskell on ghc head ----------------------------------------+---------------------------------- Reporter: schell | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: invalid | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by schell): Yes, that was the problem. After syncing it built successfully. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8421#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 10 17:28:33 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Oct 2013 17:28:33 -0000 Subject: [GHC] #8432: clarify throwTo documentation Message-ID: <044.343104dcd600c3cb51a2aebd4a3eab5b@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:32 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:32 -0000

From ghc-devs at haskell.org Thu Oct 10 17:31:11 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Oct 2013 17:31:11 -0000 Subject: [GHC] #8426: one-shot compilation + TH doesn't see instances

#8432: clarify throwTo documentation -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation Difficulty: Easy (less than 1 | bug hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- As discussed in the thread http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/23889 the documentation of {{{GHC.Conc.throwTo}}} is not 100% clear on the provided atomicity guarantees. In http://article.gmane.org/gmane.comp.lang.haskell.libraries/20218 I proposed a patch for said documentation but it seems to have slipped through the cracks. Can somebody please have a look and - hopefully - apply it? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8432 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler that is seen in batch mode In-Reply-To: <044.d5acc485a28c44206c1ed91a697769e3@haskell.org> References: <044.d5acc485a28c44206c1ed91a697769e3@haskell.org> Message-ID: <059.4430ad8def7b71835956fdbe09eab20f@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:32 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:32 -0000 #8426: one-shot compilation + TH doesn't see instances that is seen in batch mode ----------------------------+---------------------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.7 Template Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less than a day) Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: #7867 Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by simonpj): That seems plausible. But reading the transitive closure of all interface files could be thousands of files! And 90% of the time when reifying a family or class you don't actually want an exhaustive list of all possible instances in all possible modules. A possible alternative is this: remove `[InstanceDec]` from `ClassI` and `FamilyI`. Instead you have to use `qReifyInstances` to find out about instances. Because the latter has a `[Type]` you can use that to know which interface files to load. To me that sounds simpler (delete code rather than add it), without really removing useful functionality. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8426#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 10 17:35:32 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Oct 2013 17:35:32 -0000 Subject: [GHC] #8432: clarify throwTo documentation In-Reply-To: <044.343104dcd600c3cb51a2aebd4a3eab5b@haskell.org> References: <044.343104dcd600c3cb51a2aebd4a3eab5b@haskell.org> Message-ID: <059.7a6c5f82fcc6dc158cd877506f16636a@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:32 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:32 -0000

From ghc-devs at haskell.org Thu Oct 10 18:07:54 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Oct 2013 18:07:54 -0000 Subject: [GHC] #8426: one-shot compilation + TH doesn't see instances

#8432: clarify throwTo documentation -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Documentation | Difficulty: Easy (less than 1 bug | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => patch * milestone: => 7.8.1 Comment: I'll add it to Austin's patch queue, by changing the status to 'please review' (you can do this too). As you discovered, if there isn't a ticket, it's easily lost. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8432#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler that is seen in batch mode In-Reply-To: <044.d5acc485a28c44206c1ed91a697769e3@haskell.org> References: <044.d5acc485a28c44206c1ed91a697769e3@haskell.org> Message-ID: <059.21040d35e8e1e895c3ba7af50cf9c3fa@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:32 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:32 -0000 #8426: one-shot compilation + TH doesn't see instances that is seen in batch mode ----------------------------+---------------------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.7 Template Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less than a day) Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: #7867 Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by errge): Yes, the exhaustive list can be big. I agree with your plan of just removing [InstanceDec] from ClassI and FamilyI, fixing the ambiguity. But actually I need the functionality of looking up instances without types. So what if we somehow expose that functionality directly? Meaning that only those users will pay the cost who explicitly want to do that. I see two options: - (clean) adding a new Q monad method for this, - (a bit hacky) specifying that qReifyInstances with an *empty* list parameter does that. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8426#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 10 18:18:40 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Oct 2013 18:18:40 -0000 Subject: [GHC] #8424: quasi-quotes have carriage returns on Windows In-Reply-To: <048.22a0e52e93667b75ca5f688b556e6150@haskell.org> References: <048.22a0e52e93667b75ca5f688b556e6150@haskell.org> Message-ID: <063.0f4eb6f53207f2f4809aaebfbd781277@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:32 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:32 -0000

#8424: quasi-quotes have carriage returns on Windows -------------------------------------+------------------------------------ Reporter: GregWeber | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by GregWeber): So it seems that the carriage returns are not wanted. I will work with the reporter to see if we can produce a patch. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8424#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 10 19:07:56 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Oct 2013 19:07:56 -0000 Subject: [GHC] #8097: internal error: getMBlock: mmap: Operation not permitted In-Reply-To: <049.1374c35c9fb9ae4822815a0497de3a42@haskell.org> References: <049.1374c35c9fb9ae4822815a0497de3a42@haskell.org> Message-ID: <064.ba1c57a9438e16f4a9ab4cb629df5b8d@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:32 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:32 -0000

#8097: internal error: getMBlock: mmap: Operation not permitted ----------------------------------+--------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+--------------------------- Comment (by SirReal): I've experienced this as well: {{{ internal error: getMBlock: mmap: Operation not permitted (GHC version 7.4.2 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} value in /proc/sys/vm/mmap_min_addr : 65536 Here's the code that caused it: {{{ import Data.Ratio import Data.List limit :: Integer limit = 1000000 main :: IO() main = print $ "The solution is: " ++ show (countUniques allFractions) allFractions :: [Ratio Integer] allFractions = [x % y | y <- [1..limit], x <- [1..y-1]] countUniques :: Ord a => [a] -> Int countUniques = length . group . sort }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8097#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 10 19:32:24 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Oct 2013 19:32:24 -0000 Subject: [GHC] #8097: internal error: getMBlock: mmap: Operation not permitted In-Reply-To: <049.1374c35c9fb9ae4822815a0497de3a42@haskell.org> References: <049.1374c35c9fb9ae4822815a0497de3a42@haskell.org> Message-ID: <064.464ff39fe899c66ecad0b8a1e91e5e00@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:32 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:32 -0000

#8097: internal error: getMBlock: mmap: Operation not permitted ----------------------------------+------------------------------ Reporter: singpolyma | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+------------------------------ Changes (by ezyang): * status: new => infoneeded Comment: Can you reproduce on 7.6? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8097#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 10 19:42:07 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Oct 2013 19:42:07 -0000 Subject: [GHC] #8425: ghc-7.6.3: crossmodule inline leads to buggy code (-O2) In-Reply-To: <045.a29452ea9fbac42eef37cbddc5ab6d06@haskell.org> References: <045.a29452ea9fbac42eef37cbddc5ab6d06@haskell.org> Message-ID: <060.0198917aa68158065a48ab0dfae471b2@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:32 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:32 -0000

#8425: ghc-7.6.3: crossmodule inline leads to buggy code (-O2) -------------------------------------+---------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by slyfox): inliner-bug-v2.tar.gz - a bit refined monoidal's variant with dropped strict field. Now it makes final binary fail in a very fun way (maybe adds some clue): {{{ ./run_test.bash RUN good True RUN bad Main: Oops! Entered absent arg ww_s3a6{v} [lid] ghc- prim:GHC.Types.Int{(w) tc 3J} TEST FAILED in bad }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8425#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 10 19:58:46 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Oct 2013 19:58:46 -0000 Subject: [GHC] #8097: internal error: getMBlock: mmap: Operation not permitted In-Reply-To: <049.1374c35c9fb9ae4822815a0497de3a42@haskell.org> References: <049.1374c35c9fb9ae4822815a0497de3a42@haskell.org> Message-ID: <064.46a405379211c4c8e7df04be0b720250@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:33 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:33 -0000

From ghc-devs at haskell.org Thu Oct 10 20:25:40 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Oct 2013 20:25:40 -0000 Subject: [GHC] #8433: forkProcess masks async exceptions inside the child

#8097: internal error: getMBlock: mmap: Operation not permitted ----------------------------------+------------------------------ Reporter: singpolyma | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+------------------------------ Comment (by rwbarton): Hmm, interesting. I couldn't reproduce with GHC 7.4.2 on Debian Linux 2.6.32-5-686 (mmap_min_addr = 65536). What kernel version are you running (`uname -a`)? And can you run your program under strace: {{{ strace -e trace=mmap2 -o log ./countUniques }}} and attach the last page or so of `log` to this ticket? I'm 95% sure that in HEAD, you will get an out of memory error rather than this "Operation not permitted" error, but I'd like to understand what's going on here. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8097#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler process Message-ID: <044.3cf534b848ce6e2def27d6179964a4ca@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:33 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:33 -0000 #8433: forkProcess masks async exceptions inside the child process ------------------------------------+--------------------------------- Reporter: joeyh | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- Frankly, I'm not sure if this is a bug, but the forkProcess documentation says nothing about it. This can lead to problems when writing a multi- threaded daemon that expects async exceptions to work as they usually would. FWIW, I have looked at several of the libraries on hackage that handle daemonization, and none of them seem to deal with this by explicitly unmasking exceptions when running the daemon IO action. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8433 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 10 20:56:34 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Oct 2013 20:56:34 -0000 Subject: [GHC] #8434: dynflag dependency addition in TcRnDriver is not needed anymore Message-ID: <044.18b1fa8e0bffb7cf60a63e5a38f86534@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:33 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:33 -0000

#8434: dynflag dependency addition in TcRnDriver is not needed anymore -------------------------------------------+------------------------------- Reporter: errge | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: -------------------------------------------+------------------------------- The removed parts of the tcRnImports function in the attached patch says that there is a check in LoadIface.loadInterface and this is why it's needed to add the plugin dependencies to the EPS. But actually [[GhcFile(compiler/iface/LoadIface.lhs#L227)]] says that the check is no longer there. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8434 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 10 20:57:11 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Oct 2013 20:57:11 -0000 Subject: [GHC] #8434: dynflag dependency addition in TcRnDriver is not needed anymore In-Reply-To: <044.18b1fa8e0bffb7cf60a63e5a38f86534@haskell.org> References: <044.18b1fa8e0bffb7cf60a63e5a38f86534@haskell.org> Message-ID: <059.51f84233c1ef28ed1dda5911601d837a@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:33 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:33 -0000

#8434: dynflag dependency addition in TcRnDriver is not needed anymore -------------------------------+------------------------------------------- Reporter: errge | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------+------------------------------------------- Changes (by errge): * status: new => patch -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8434#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 10 21:02:08 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Oct 2013 21:02:08 -0000 Subject: [GHC] #8425: ghc-7.6.3: crossmodule inline leads to buggy code (-O2) In-Reply-To: <045.a29452ea9fbac42eef37cbddc5ab6d06@haskell.org> References: <045.a29452ea9fbac42eef37cbddc5ab6d06@haskell.org> Message-ID: <060.140ba0edde1bae9c9c7e3103a7a2b9ce@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:33 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:33 -0000

#8425: ghc-7.6.3: crossmodule inline leads to buggy code (-O2) -------------------------------------+---------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by slyfox): My theory is the bug is induced by '''{-# INLINABLE insert #-}''' and '''{-# INLINABLE lookup #-}''' pragmas. It makes Main module use '''BuggyOpt.$sinsert''' specialisation (with it's environment taken into account). It's seen nicely when we build Main in both modes: good (all ok: Base.lookup): {{{ ==================== Occurrence analysis ==================== [snip instances] Main.mkLin :: Arr.Array GHC.Types.Int -> Base.Map (Arr.Array GHC.Types.Int) GHC.Types.Int [LclIdX, Arity=1, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=1, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0] 110 0}] Main.mkLin = \ (mseqs_amq :: Arr.Array GHC.Types.Int) -> case Base.lookup @ (Arr.Array GHC.Types.Int) @ (GHC.Prim.Any *) (Arr.$fEqArray @ GHC.Types.Int) mseqs_amq (Base.empty @ (Arr.Array GHC.Types.Int) @ (GHC.Prim.Any *)) of _ { __DEFAULT -> Base.insert @ (Arr.Array GHC.Types.Int) @ GHC.Types.Int $dOrd_apD mseqs_amq (GHC.Types.I# 1) (Base.empty @ (Arr.Array GHC.Types.Int) @ GHC.Types.Int) } }}} bad (note BuggyOpt.$sinsert on an early phase): {{{ ==================== Occurrence analysis ==================== Main.mkLin :: Arr.Array GHC.Types.Int -> Base.Map (Arr.Array GHC.Types.Int) GHC.Types.Int [LclIdX, Arity=1, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=1, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0] 100 0}] Main.mkLin = \ (mseqs_amy :: Arr.Array GHC.Types.Int) -> case Base.lookup @ (Arr.Array GHC.Types.Int) @ (GHC.Prim.Any *) (Arr.$fEqArray @ GHC.Types.Int) mseqs_amy (Base.empty @ (Arr.Array GHC.Types.Int) @ (GHC.Prim.Any *)) of _ { __DEFAULT -> BuggyOpt.$sinsert @ GHC.Types.Int mseqs_amy (GHC.Types.I# 1) (Base.empty @ (Arr.Array GHC.Types.Int) @ GHC.Types.Int) } }}} Does it look suspicious? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8425#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 10 21:43:47 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Oct 2013 21:43:47 -0000 Subject: [GHC] #8338: Incoherent instances without -XIncoherentInstances In-Reply-To: <047.a0d089b6b93e7c7be0249b8f78624b22@haskell.org> References: <047.a0d089b6b93e7c7be0249b8f78624b22@haskell.org> Message-ID: <062.142ea51eb7a41de37ae438b4d15ae0af@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:33 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:33 -0000

#8338: Incoherent instances without -XIncoherentInstances -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by illissius): I might be missing something important, but it seems to me that the answer is very obviously 4. I'm not familiar with the precise language of the standard, but I always understood the rule to be very simple: "thou shalt have no more than one instance of a class for a type in thy program". We're blatantly violating this rule, the question is why GHC is not catching us. I think the answer is that you've come up with a way to distinguish GHC's lazy checking of instance overlap from other compilers' eager checking, to GHC's detriment. There's no use of a `Show One` instance in `D`, so GHC doesn't bother to investigate it. If overlap were checked eagerly at imports instead of lazily at use sites, the error would be caught. Obviously there must be a reason why GHC does lazy rather than eager checking (and I think it might have something to do with `Overlapping`- and `IncoherentInstances`?), but I don't know the specifics. What would break if overlap checking were eager?

We could prohibit importing two modules that export conflicting instances. But, that would cause interoperability problems between different modules/packages that define overlapping instances.

Do you mean overlapping instances using `OverlappingInstances`, or without it? In the latter case I think it's the absence of interoperability problems that should count as a bug. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8338#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 10 21:56:51 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Oct 2013 21:56:51 -0000 Subject: [GHC] #8435: Do not copy stack after stack overflow Message-ID: <045.54f81ed32448cf035819222e39f1dbaf@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:33 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:33 -0000

#8435: Do not copy stack after stack overflow ------------------------------+-------------------------------------------- Reporter: ezyang | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.7 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime performance bug Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- I am not sure, but I was doing a close reading of `threadStackOverflow` and noticed that after we throw a stack overflow exception, we fall through to the code responsible for allocating a new stack and copying the code over. An old iteration of the stack overflow code (removed in the commit cited below) did return after throwing the exception, and I did not see anything in the commit message suggesting the change was intentional. It seems sound to copy the stack; it will just become dead immediately. The relevant commit: {{{ commit f30d527344db528618f64a25250a3be557d9f287 Author: Simon Marlow <marlowsd at gmail.com> Date: Wed Dec 15 12:08:43 2010 +0000 Implement stack chunks and separate TSO/STACK objects }}} Suggested (untested) patch: {{{ diff --git a/rts/Threads.c b/rts/Threads.c index 742119d..ccd6b17 100644 --- a/rts/Threads.c +++ b/rts/Threads.c @@ -533,6 +533,7 @@ threadStackOverflow (Capability *cap, StgTSO *tso) // Send this thread the StackOverflow exception throwToSingleThreaded(cap, tso, (StgClosure *)stackOverflow_closure); + return; } }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8435 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 10 22:04:14 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Oct 2013 22:04:14 -0000 Subject: [GHC] #7774: T5313 fails In-Reply-To: <044.269de52e286e977138cf795af4626d88@haskell.org> References: <044.269de52e286e977138cf795af4626d88@haskell.org> Message-ID: <059.a4716aa07fc413935e3351e757f000ea@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:34 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:34 -0000

#7774: T5313 fails -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: GHC API | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by gmainland): Yes it is, but the error is slightly different: {{{ =====> T5313(normal) 2009 of 3799 [0, 0, 0] cd ./driver && '/home/mainland/ghc/ghc-working-build/inplace/bin/ghc- stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user- package-db -rtsopts -fno-ghci-history -o T5313 T5313.hs -package ghc

T5313.comp.stderr 2>&1 cd ./driver && ./T5313 "/home/mainland/ghc/ghc-working-build/inplace/lib" T5313.run.stdout 2>T5313.run.stderr Wrong exit code (expected 0 , actual 1 ) Stdout:

Stderr: T5313: <command line>: can't load .so/.DLL for: /home/mainland/ghc/ghc- working-build/libraries/ghc-prim/dist-install/build/libHSghc- prim-0.3.1.0-ghc7.7.20131010.so (/home/mainland/ghc/ghc-working- build/libraries/ghc-prim/dist-install/build/libHSghc- prim-0.3.1.0-ghc7.7.20131010.so: undefined symbol: stg_forkOnzh) }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7774#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Thu Oct 10 23:10:52 2013 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Oct 2013 23:10:52 -0000 Subject: [GHC] #3722: Haskeline Iconv needs HAVE_LANGINFO_H In-Reply-To: <043.b0b3ab959578ffb5ff45ff74152ccd8c@haskell.org> References: <043.b0b3ab959578ffb5ff45ff74152ccd8c@haskell.org> Message-ID: <058.5511ce9c131ffe7fc906721463f7fab3@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:34 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:34 -0000

#3722: Haskeline Iconv needs HAVE_LANGINFO_H ----------------------------------------+------------------------------ Reporter: donn | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.6.2 Component: libraries (other) | Version: 6.12.1 RC1 Resolution: fixed | Keywords: Operating System: Other | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+------------------------------ Changes (by judahj): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: This has been fixed in haskeline, which tests for HAVE_LIBCHARSET before HAVE_LANGINFO_H: https://github.com/ghc/packages- base/commit/b56d2e60a1141e9fc23d795b5b7222921670a285 If that does not resolve the issue for you, please let us know. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/3722#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 00:08:15 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 00:08:15 -0000 Subject: [GHC] #8139: ghc 7.6.3 and ghc HEAD fails to build on OS X 10.9 In-Reply-To: <052.92009bd3b6836bd26916c16cd983224b@haskell.org> References: <052.92009bd3b6836bd26916c16cd983224b@haskell.org> Message-ID: <067.3bd50496c9b4359f41f285a2f8f9d1bb@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:34 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:34 -0000

#8139: ghc 7.6.3 and ghc HEAD fails to build on OS X 10.9 -------------------------------------+------------------------------------- Reporter: darinmorrison | Owner: darinmorrison Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by kazu-yamamoto): * cc: kazu@? (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8139#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 00:53:19 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 00:53:19 -0000 Subject: [GHC] #8436: Stack overflow when masked should still throw at interruptible operations or inner unmask Message-ID: <045.92b768b2dd28a667b372d66f0a4f0cb2@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:34 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:34 -0000

#8436: Stack overflow when masked should still throw at interruptible operations or inner unmask -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Incorrect result Difficulty: Easy (less than 1 | at runtime hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Currently, to deal with #767, stack overflow exceptions are never emitted when exceptions are masked; e.g. if the thread unmasks and it is back under the stack limit, it will be as if the thread never stack-overflowed. However, it seems that we can be a bit more proactive about throwing the exception, in a way similar to asynchronous exceptions, wherein we add the stack overflow to the blocked exceptions list and let it be thrown at an interruptible point or if the exceptions get unmasked. Patch would be pretty simple, I'd like to check if people think this is a better idea. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8436 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 01:01:15 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 01:01:15 -0000 Subject: [GHC] #8436: Stack overflow when masked should still throw at interruptible operations or inner unmask In-Reply-To: <045.92b768b2dd28a667b372d66f0a4f0cb2@haskell.org> References: <045.92b768b2dd28a667b372d66f0a4f0cb2@haskell.org> Message-ID: <060.f3bf44fbd11606eac607d34b2565febd@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:34 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:34 -0000

#8436: Stack overflow when masked should still throw at interruptible operations or inner unmask -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: bug | Status: closed Priority: low | Milestone: Component: Runtime System | Version: 7.7 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: 8303 -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => duplicate * related: => 8303 Comment: Duplicate of #8303 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8436#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 01:43:14 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 01:43:14 -0000 Subject: [GHC] #8303: defer StackOverflow exceptions (rather than dropping them) when exceptions are masked In-Reply-To: <047.f5c1e98e88fb0e535a65a8bb76dcd836@haskell.org> References: <047.f5c1e98e88fb0e535a65a8bb76dcd836@haskell.org> Message-ID: <062.456d8feec67e22f2f665c1af1e78ec8b@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:34 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:34 -0000

#8303: defer StackOverflow exceptions (rather than dropping them) when exceptions are masked -------------------------------+------------------------------------------- Reporter: rwbarton | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.7 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by ezyang): * cc: simonmar (added) * difficulty: Unknown => Easy (less than 1 hour) * version: 7.6.3 => 7.7 * owner: => ezyang Comment: Posted an untested patch I am validating. It is a little bit of a hack, but not very much. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8303#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 02:08:13 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 02:08:13 -0000 Subject: [GHC] #8338: Incoherent instances without -XIncoherentInstances In-Reply-To: <047.a0d089b6b93e7c7be0249b8f78624b22@haskell.org> References: <047.a0d089b6b93e7c7be0249b8f78624b22@haskell.org> Message-ID: <062.a7105b4c30473dff865be01ffd2ce45c@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:34 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:34 -0000

#8338: Incoherent instances without -XIncoherentInstances -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): In my comment, I was referring to overlapping instances from modules that ''don't'' use `OverlappingInstaces`. Here's how I can see it happening: * Suppose package `dayta` exports a datatype `T` and package `klass` exports a class `C`. * Now, packages `a` and `b` both import `T` and `C` from their respective packages and define an instance `C T`. * Package `c` wants to use the relevant modules from both `a` and `b`. Disaster with eager checking of overlap. I've used packages here instead of modules to emphasize that the authors of all of these parts may be different. From a technical standpoint, replacing "package" with "module" would also work here. I should say I'm not really disagreeing with illissius about eager checking, just drawing out the example of where this might be a problem. I find it very hard to come up with an opinion on this issue that I would feel comfortable defending! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8338#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 03:59:55 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 03:59:55 -0000 Subject: [GHC] #8301: error BaseReg must be in a register for THREADED_RTS In-Reply-To: <044.0651fb01dd71f2601e90f46aa455c558@haskell.org> References: <044.0651fb01dd71f2601e90f46aa455c558@haskell.org> Message-ID: <059.90d6b1c95a27a948fe084f54280272c3@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:34 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:34 -0000

#8301: error BaseReg must be in a register for THREADED_RTS ----------------------------------------+----------------------------- Reporter: erikd | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by rwbarton): gustavold on #ghc encountered the same error and ran the failing command with -v. The output is here: http://paste.fedoraproject.org/45986/13814634 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8301#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 04:21:52 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 04:21:52 -0000 Subject: [GHC] #8301: error BaseReg must be in a register for THREADED_RTS In-Reply-To: <044.0651fb01dd71f2601e90f46aa455c558@haskell.org> References: <044.0651fb01dd71f2601e90f46aa455c558@haskell.org> Message-ID: <059.9ef8c146fa514cbd0ba6315964ce9460@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:35 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:35 -0000

#8301: error BaseReg must be in a register for THREADED_RTS ----------------------------------------+----------------------------- Reporter: erikd | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by gustavold): That pastebin will expire very soon. I added the output of "ghc-stage1 -v" as an attachment for future reference. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8301#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 04:23:12 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 04:23:12 -0000 Subject: [GHC] #8301: error BaseReg must be in a register for THREADED_RTS In-Reply-To: <044.0651fb01dd71f2601e90f46aa455c558@haskell.org> References: <044.0651fb01dd71f2601e90f46aa455c558@haskell.org> Message-ID: <059.81a98cea5bc17c8e350b71bc916fea54@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:35 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:35 -0000

#8301: error BaseReg must be in a register for THREADED_RTS ----------------------------------------+----------------------------- Reporter: erikd | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Changes (by gustavold): * cc: gustavold@? (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8301#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 07:29:23 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 07:29:23 -0000 Subject: [GHC] #8303: defer StackOverflow exceptions (rather than dropping them) when exceptions are masked In-Reply-To: <047.f5c1e98e88fb0e535a65a8bb76dcd836@haskell.org> References: <047.f5c1e98e88fb0e535a65a8bb76dcd836@haskell.org> Message-ID: <062.86fc5b991fc89e5f0fcf1ab695d06f65@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:35 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:35 -0000

#8303: defer StackOverflow exceptions (rather than dropping them) when exceptions are masked -------------------------------+------------------------------------------- Reporter: rwbarton | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime | Version: 7.7 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by ezyang): * status: new => patch Comment: Posted a new patch that validates. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8303#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 07:33:54 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 07:33:54 -0000 Subject: [GHC] #8434: dynflag dependency addition in TcRnDriver is not needed anymore In-Reply-To: <044.18b1fa8e0bffb7cf60a63e5a38f86534@haskell.org> References: <044.18b1fa8e0bffb7cf60a63e5a38f86534@haskell.org> Message-ID: <059.512fce764bdc74c44f0afc3bc8babfc9@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:35 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:35 -0000

#8434: dynflag dependency addition in TcRnDriver is not needed anymore -------------------------------+------------------------------------------- Reporter: errge | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------+------------------------------------------- Old description:

The removed parts of the tcRnImports function in the attached patch says that there is a check in LoadIface.loadInterface and this is why it's needed to add the plugin dependencies to the EPS.

But actually [[GhcFile(compiler/iface/LoadIface.lhs#L227)]] says that the check is no longer there.

New description: The removed parts of the `tcRnImports` function in the attached patch says that there is a check in `LoadIface.loadInterface` and this is why it's needed to add the plugin dependencies to the EPS. But actually [[GhcFile(compiler/iface/LoadIface.lhs#L227)]] says that the check is no longer there. -- Comment (by simonpj): Yes ok I agree. Austin, please apply. (errge, you did validate didn't you) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8434#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 08:10:56 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 08:10:56 -0000 Subject: [GHC] #8097: internal error: getMBlock: mmap: Operation not permitted In-Reply-To: <049.1374c35c9fb9ae4822815a0497de3a42@haskell.org> References: <049.1374c35c9fb9ae4822815a0497de3a42@haskell.org> Message-ID: <064.4388550426f985eabf350d9e3634b468@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:35 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:35 -0000

#8097: internal error: getMBlock: mmap: Operation not permitted ----------------------------------+------------------------------ Reporter: singpolyma | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+------------------------------ Comment (by SirReal): Replying to [comment:3 ezyang]:

Can you reproduce on 7.6?

I've tested the same code on another machine with 7.6 with no problem. I don't really have time to install 7.6 on the original machine right now. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8097#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 08:25:15 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 08:25:15 -0000 Subject: [GHC] #8437: pprCallishMachOp_for_C: MO_Prefetch_Data 0 not supported Message-ID: <044.b8f976d3fed1b8312bbd200602ccf39f@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:35 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:35 -0000

#8437: pprCallishMachOp_for_C: MO_Prefetch_Data 0 not supported -----------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: powerpc64 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -----------------------------+------------------------------------- Compiling on linux-powerpc64, the build fails on: {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.7.20131010 for powerpc64-unknown-linux): pprCallishMachOp_for_C: MO_Prefetch_Data 0 not supported! Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} From file `compiler/cmm/PprC.hs` : {{{ (MO_Prefetch_Data _ ) -> unsupported --- we could support prefetch via "__builtin_prefetch" --- Not adding it for now }}} Anyone have ideas on how to make this work? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8437 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 08:25:23 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 08:25:23 -0000 Subject: [GHC] #8097: internal error: getMBlock: mmap: Operation not permitted In-Reply-To: <049.1374c35c9fb9ae4822815a0497de3a42@haskell.org> References: <049.1374c35c9fb9ae4822815a0497de3a42@haskell.org> Message-ID: <064.e06b73f7397eab9fe7e2e395b9b64de8@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:35 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:35 -0000

Hmm, interesting. I couldn't reproduce with GHC 7.4.2 on Debian Linux 2.6.32-5-686 (mmap_min_addr = 65536). How are you building your program (e.g., are you using `-O2`)? What kernel version are you running (`uname -a`)? And can you run your program under strace: {{{ strace -e trace=mmap2 -o log ./countUniques }}} and attach the last page or so of `log` to this ticket?

I'm 95% sure that in HEAD, you will get an out of memory error rather

#8097: internal error: getMBlock: mmap: Operation not permitted ----------------------------------+------------------------------ Reporter: singpolyma | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+------------------------------ Comment (by SirReal): Replying to [comment:4 rwbarton]: than this "Operation not permitted" error, but I'd like to understand what's going on here. The build was: {{{ghc -Werror -Wall -O2}}} I've attached the end of the log. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8097#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 08:27:44 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 08:27:44 -0000 Subject: [GHC] #8435: Do not copy stack after stack overflow In-Reply-To: <045.54f81ed32448cf035819222e39f1dbaf@haskell.org> References: <045.54f81ed32448cf035819222e39f1dbaf@haskell.org> Message-ID: <060.b97b45340286ade85b6fa3c6cfe9533b@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:35 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:35 -0000

#8435: Do not copy stack after stack overflow --------------------------------------------+------------------------------ Reporter: ezyang | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonmar): Sounds reasonable to me. If it validates, go ahead and push. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8435#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 08:28:51 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 08:28:51 -0000 Subject: [GHC] #8437: pprCallishMachOp_for_C: MO_Prefetch_Data 0 not supported In-Reply-To: <044.b8f976d3fed1b8312bbd200602ccf39f@haskell.org> References: <044.b8f976d3fed1b8312bbd200602ccf39f@haskell.org> Message-ID: <059.f98c3f43002a7c7d45bc9878e428ed94@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:35 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:35 -0000

#8437: pprCallishMachOp_for_C: MO_Prefetch_Data 0 not supported -------------------------------------+----------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+----------------------------- Comment (by erikd): The function prototype for `__builtin_prefetch` is: {{{ void __builtin_prefetch( const void *addr, int rw, int locality ) }}} but the `MO_Prefetch_Data` constructor only has one element. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8437#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 08:34:27 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 08:34:27 -0000 Subject: [GHC] #8429: GHC.Base.{breakpoint, breakpointCond} do nothing In-Reply-To: <045.4c9eb90270eb503495dbeb412abc60e7@haskell.org> References: <045.4c9eb90270eb503495dbeb412abc60e7@haskell.org> Message-ID: <060.9371d971e12265431334ae06b076760d@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:36 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:36 -0000

#8429: GHC.Base.{breakpoint, breakpointCond} do nothing -------------------------------------+------------------------------------ Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 1377 -------------------------------------+------------------------------------ Comment (by simonmar): Yes, it looks like all of `GHC.Exts.{breakpoint,breakpointCond,Opaque}` are dead code, as are these in `PrelNames`: {{{ breakpointName = varQual gHC_BASE (fsLit "breakpoint") breakpointIdKey breakpointCondName= varQual gHC_BASE (fsLit "breakpointCond") breakpointCondIdKey breakpointAutoName= varQual gHC_BASE (fsLit "breakpointAuto") breakpointAutoIdKey opaqueTyConName = tcQual gHC_BASE (fsLit "Opaque") opaqueTyConKey }}} Would someone like to go ahead and remove them? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8429#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 08:41:08 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 08:41:08 -0000 Subject: [GHC] #3553: parallel gc suffers badly if one thread is descheduled In-Reply-To: <047.48e7cf5ad32bf05ce8bca6e11b9273f8@haskell.org> References: <047.48e7cf5ad32bf05ce8bca6e11b9273f8@haskell.org> Message-ID: <062.7c655928d5e65c45293b347fa9c2944b@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:36 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:36 -0000

#3553: parallel gc suffers badly if one thread is descheduled -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.2 Component: Runtime System | Version: 6.10.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): Replying to [comment:14 parcs]:

If so, would the earlier commits that helped mitigate this particular slowdown be undone (like the one that makes `ACQUIRE_SPIN_LOCK()` call `yieldThread()` every 1000 spins)?

No, the problem is still very real, and the `yieldThread()` helps a lot. Making the main thread non-bound would just make it less likely to manifest in some cases. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/3553#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 08:41:30 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 08:41:30 -0000 Subject: [GHC] #8434: dynflag dependency addition in TcRnDriver is not needed anymore In-Reply-To: <044.18b1fa8e0bffb7cf60a63e5a38f86534@haskell.org> References: <044.18b1fa8e0bffb7cf60a63e5a38f86534@haskell.org> Message-ID: <059.a0063152dce83fdd6bb2029209cf8d45@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:36 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:36 -0000

#8434: dynflag dependency addition in TcRnDriver is not needed anymore -------------------------------+------------------------------------------- Reporter: errge | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------+------------------------------------------- Comment (by errge): I did a: `make -C testsuite fast THREADS=6 VERBOSE=2 SKIP_PERF_TESTS=YES` -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8434#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 08:46:47 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 08:46:47 -0000 Subject: [GHC] #8303: defer StackOverflow exceptions (rather than dropping them) when exceptions are masked In-Reply-To: <047.f5c1e98e88fb0e535a65a8bb76dcd836@haskell.org> References: <047.f5c1e98e88fb0e535a65a8bb76dcd836@haskell.org> Message-ID: <062.4cb1194dd8f6d02969c75fb415226b81@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:36 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:36 -0000

#8303: defer StackOverflow exceptions (rather than dropping them) when exceptions are masked -------------------------------+------------------------------------------- Reporter: rwbarton | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime | Version: 7.7 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by simonmar): This is a very clever trick, and it has a certain devious beauty. I have no idea if we're going to trip up an assumption somewhere by having a throwTo message where the source and the destination are the same thread, but I'm happy to take the risk (and I'm sure we can fix up any breakage that results). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8303#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 08:49:25 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 08:49:25 -0000 Subject: [GHC] #8303: defer StackOverflow exceptions (rather than dropping them) when exceptions are masked In-Reply-To: <047.f5c1e98e88fb0e535a65a8bb76dcd836@haskell.org> References: <047.f5c1e98e88fb0e535a65a8bb76dcd836@haskell.org> Message-ID: <062.7ab8802586d1ae59747a58d8c89cd4c6@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:36 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:36 -0000

#8303: defer StackOverflow exceptions (rather than dropping them) when exceptions are masked -------------------------------+------------------------------------------- Reporter: rwbarton | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime | Version: 7.7 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by simonpj): "a clever trick, with devious beauty". I love the sound of that, but Edward can you make sure there is a clear `Note [Clever trick of devious beauty]` to document the intent and explain how it works? Thanks. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8303#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 10:32:33 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 10:32:33 -0000 Subject: [GHC] #8180: Template Haskell now requires -dynamic or -dynamic-too (was: ghc --make uses wrong way with Template Haskell) In-Reply-To: <047.1c653d82d918be711217186a104a0ee9@haskell.org> References: <047.1c653d82d918be711217186a104a0ee9@haskell.org> Message-ID: <062.f32ec11f60ae7688f603d63fefca0823@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:37 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:37 -0000

#8180: Template Haskell now requires -dynamic or -dynamic-too -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonmar): * cc: igloo (added) * priority: normal => highest * architecture: x86_64 (amd64) => Unknown/Multiple * milestone: => 7.8.1 * os: MacOS X => Unknown/Multiple Comment: We must do something about this, I think it's going to cause a lot of grief after 7.8.1 comes out. If you compile a program with TemplateHaskell (or Annotations), it now fails unless you also use `-dynamic` or `-dynamic-too`. And if you use `-dynamic-too` with `-o`, you also get this bogus-looking error: {{{ '/home/simon/code-all/work/ghc-validate/inplace/bin/ghc-stage2' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history --make -o TH_spliceE5 TH_spliceE5.hs -v0 -XTemplateHaskell -package template-haskell -dynamic-too <command line>: With -dynamic-too, must give -dyno iff giving -o }}} At the very least, we need to document this very clearly - I didn't see it mentioned in the release notes. But I don't think that's enough: it should just work, as @goldfire says. Perhaps `TemplateHaskell` should imply `-dynamic-too`? But what if you only have `TemplateHaskell` in a few modules of your program? We can't go back to the beginning and recompile. Presumably Cabal doesn't have this problem because it always uses `-dynamic-too` now. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8180#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 10:35:13 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 10:35:13 -0000 Subject: [GHC] #8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault In-Reply-To: <046.a1de52e736c53bf94deece978e2702d5@haskell.org> References: <046.a1de52e736c53bf94deece978e2702d5@haskell.org> Message-ID: <061.6ed3dbe5ace60ad163a81297bfee1952@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:37 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:37 -0000

#8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------+---------------------------------- Reporter: darchon | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by Simon Marlow ): In [changeset:"b9c6fd72cd8a00e7c3604567fc4170a3f6421d71/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b9c6fd72cd8a00e7c3604567fc4170a3f6421d71" Use dynamic linking only if the GHC package is compiled with -dynamic (#8376) }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8376#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 10:35:15 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 10:35:15 -0000 Subject: [GHC] #8402: throwTo segfaults under -prof -threaded -with-rtsopts=N2 In-Reply-To: <043.0ab089710edd4b363b63a9d75aa20e5f@haskell.org> References: <043.0ab089710edd4b363b63a9d75aa20e5f@haskell.org> Message-ID: <058.ef140479c103e903337282f5b2330f9a@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:37 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:37 -0000

#8402: throwTo segfaults under -prof -threaded -with-rtsopts=N2 ----------------------------------+---------------------------------- Reporter: akio | Owner: simonmar Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Profiling | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by Simon Marlow ): In [changeset:"8ea8c371f345e3a265d425b37e793d8b553a1588/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8ea8c371f345e3a265d425b37e793d8b553a1588" Fix up the conditions for zeroing slop (#8402) }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8402#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 10:40:56 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 10:40:56 -0000 Subject: [GHC] #8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault In-Reply-To: <046.a1de52e736c53bf94deece978e2702d5@haskell.org> References: <046.a1de52e736c53bf94deece978e2702d5@haskell.org> Message-ID: <061.0400c6e1dda29221334edf9dbc4d66a9@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:38 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:38 -0000

#8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------+---------------------------------- Reporter: darchon | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by simonmar): I made it so that the GHC package will work when linked into both static and dynamic programs. This is really a lie, because the RTS linker doesn't work on all platforms (64-bit Windows, and probably Mac OS X), so there's still more to do: we have to explicitly fail if the platform doesn't support static linking. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8376#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 10:42:15 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 10:42:15 -0000 Subject: [GHC] #8402: throwTo segfaults under -prof -threaded -with-rtsopts=N2 In-Reply-To: <043.0ab089710edd4b363b63a9d75aa20e5f@haskell.org> References: <043.0ab089710edd4b363b63a9d75aa20e5f@haskell.org> Message-ID: <058.3596857945242cf72f3dfa232c03fd66@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:38 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:38 -0000

#8402: throwTo segfaults under -prof -threaded -with-rtsopts=N2 ----------------------------------+---------------------------------- Reporter: akio | Owner: simonmar Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Profiling | Version: 7.7 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by simonmar): * status: patch => closed * resolution: => fixed Comment: Reasonably sure I have this right now. Also updated the comments. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8402#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 10:42:18 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 10:42:18 -0000 Subject: [GHC] #8180: Template Haskell now requires -dynamic or -dynamic-too In-Reply-To: <047.1c653d82d918be711217186a104a0ee9@haskell.org> References: <047.1c653d82d918be711217186a104a0ee9@haskell.org> Message-ID: <062.5c62607607ff42ea41963b40fc0cc6dd@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:38 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:38 -0000

#8180: Template Haskell now requires -dynamic or -dynamic-too -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by refold): Yes, I fixed Cabal to use `-dynamic-too` when needed. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8180#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 12:30:49 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 12:30:49 -0000 Subject: [GHC] #8429: GHC.Base.{breakpoint, breakpointCond} do nothing In-Reply-To: <045.4c9eb90270eb503495dbeb412abc60e7@haskell.org> References: <045.4c9eb90270eb503495dbeb412abc60e7@haskell.org> Message-ID: <060.4d28f8528109341914c239ed41b999f3@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:38 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:38 -0000

#8429: GHC.Base.{breakpoint, breakpointCond} do nothing -------------------------------------+------------------------------------ Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 1377 -------------------------------------+------------------------------------ Comment (by refold): Replying to [comment:3 simonmar]:

Would someone like to go ahead and remove them?

Would it be possible to make them work again? I'm willing to write a patch if someone gives me advice on where to start. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8429#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 13:54:59 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 13:54:59 -0000 Subject: [GHC] #8303: defer StackOverflow exceptions (rather than dropping them) when exceptions are masked In-Reply-To: <047.f5c1e98e88fb0e535a65a8bb76dcd836@haskell.org> References: <047.f5c1e98e88fb0e535a65a8bb76dcd836@haskell.org> Message-ID: <062.959addd0941de44262c55fd07eb2f344@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:38 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:38 -0000

#8303: defer StackOverflow exceptions (rather than dropping them) when exceptions are masked -------------------------------+------------------------------------------- Reporter: rwbarton | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime | Version: 7.7 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by rwbarton): Here is a test, adapted from the original program. I tested that it fails currently and passes if I replace `(hPutStrLn h "Hi")` by `(return ())`; I haven't tested your patch, Edward. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8303#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 14:25:13 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 14:25:13 -0000 Subject: [GHC] #8180: Template Haskell now requires -dynamic or -dynamic-too In-Reply-To: <047.1c653d82d918be711217186a104a0ee9@haskell.org> References: <047.1c653d82d918be711217186a104a0ee9@haskell.org> Message-ID: <062.9bcd72a126a79dca17058582b2ab9e23@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:39 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:39 -0000

#8180: Template Haskell now requires -dynamic or -dynamic-too -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Just to understand, 7.6.3 would link `THSplice.o` when compiling `Main.h`, right? But 7.8 will not? So you have to compile `THSplice` with `dynamic-too` in order to create `THSplice.dyn_o`? So what is the Right Thing here? * Be able to link `THSplice.o`? * Produce a better error message? or what? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8180#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 15:32:29 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 15:32:29 -0000 Subject: [GHC] #8437: pprCallishMachOp_for_C: MO_Prefetch_Data 0 not supported In-Reply-To: <044.b8f976d3fed1b8312bbd200602ccf39f@haskell.org> References: <044.b8f976d3fed1b8312bbd200602ccf39f@haskell.org> Message-ID: <059.9e92f4282f72e35d4d1c9ab31d55dd0f@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:39 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:39 -0000

#8437: pprCallishMachOp_for_C: MO_Prefetch_Data 0 not supported -------------------------------------+----------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+----------------------------- Comment (by rwbarton): Funny, someone else (I assume!) was also building HEAD on linux-powerpc64 last night and ran into this same issue. For now, you can try this (untested) patch to simply make prefetches a no- op in the C backend: http://lpaste.net/94144 Ideally, you would output a `__builtin_prefetch` call where `rw` is 0, `locality` is the argument of the `MO_Prefetch_Data` constructor, and `addr` comes from the `args` field of the `CmmUnsafeForeignCall`. That looks pretty easy to do, by adding another special case for `fn_addr` and sending `MO_Prefetch_Data _` to `__builtin_prefetch` in `pprCallishMachOp_for_C`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8437#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 17:27:09 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 17:27:09 -0000 Subject: [GHC] #8084: Enabling PolyKinds makes some type errors weird In-Reply-To: <060.9468f9547ded02065da30dc6912ba7f5@haskell.org> References: <060.9468f9547ded02065da30dc6912ba7f5@haskell.org> Message-ID: <075.932f755229d001adf8ac15d82ee49931@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:39 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:39 -0000

#8084: Enabling PolyKinds makes some type errors weird --------------------------------------------+------------------------------ Reporter: MartijnVanSteenbergen | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by monoidal): * status: new => closed * resolution: => fixed Comment: This is fixed in HEAD (see #8357 for commits). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8084#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 17:32:26 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 17:32:26 -0000 Subject: [GHC] #7477: reifyInstances can't deal with polykinded type families In-Reply-To: <047.0f99aec0c8f4caa3ebd2125e9160967e@haskell.org> References: <047.0f99aec0c8f4caa3ebd2125e9160967e@haskell.org> Message-ID: <062.1f2a79cd5f9a625665a7bee30dde4cc1@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:39 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:39 -0000

#7477: reifyInstances can't deal with polykinded type families -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: new Type: bug | Milestone: 7.8.1 Priority: | Version: 7.7 normal | Keywords: TemplateHaskell TypeFamilies Component: | PolyKinds Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------+------------------------------------------------- Comment (by monoidal): For what's worth, we now get an empty warning. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7477#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 18:01:26 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 18:01:26 -0000 Subject: [GHC] #8437: pprCallishMachOp_for_C: MO_Prefetch_Data 0 not supported In-Reply-To: <044.b8f976d3fed1b8312bbd200602ccf39f@haskell.org> References: <044.b8f976d3fed1b8312bbd200602ccf39f@haskell.org> Message-ID: <059.96d83b71408419026c1dc185bb55fe2b@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:39 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:39 -0000

#8437: pprCallishMachOp_for_C: MO_Prefetch_Data 0 not supported -------------------------------------+----------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+----------------------------- Comment (by carter): urk, this is absolutely my fault, I didn't realize the c backend is used anymore! (seriously, had no idea, thought it was just a bitrotting thing in tree....). Otherwise i'd have added that too. My sincerest apologies for that. reid's noop patch and sketch for how to do prefetch right sound. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8437#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 18:28:37 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 18:28:37 -0000 Subject: [GHC] #8303: defer StackOverflow exceptions (rather than dropping them) when exceptions are masked In-Reply-To: <047.f5c1e98e88fb0e535a65a8bb76dcd836@haskell.org> References: <047.f5c1e98e88fb0e535a65a8bb76dcd836@haskell.org> Message-ID: <062.2a085cc0ae3c96371e0cecae5568af8b@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:39 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:39 -0000

#8303: defer StackOverflow exceptions (rather than dropping them) when exceptions are masked -------------------------------+------------------------------------------- Reporter: rwbarton | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime | Version: 7.7 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by ezyang): {{{ =====> T8303(normal) 59 of 3801 [0, 0, 0] cd ./rts && '/home/hs01/ezyang/ghc-stackoverflow/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package- db -rtsopts -fno-ghci-history -o T8303 T8303.hs >T8303.comp.stderr 2>&1 cd ./rts && ./T8303 +RTS -K2K -RTS T8303.run.stdout 2>T8303.run.stderr OVERALL SUMMARY for test run started at Fri Oct 11 11:24:21 2013 PDT 0:00:02 spent to go through 3801 total tests, which gave rise to 14943 test cases, of which 14942 were skipped 0 had missing libraries 1 expected passes 0 expected failures }}} I'll go ahead and add extra docs, and then push. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8303#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 21:58:27 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 21:58:27 -0000 Subject: [GHC] #8320: Build fails due to Haddock error in ghc-prim:GHC.Types In-Reply-To: <044.d03a5005166332b97ad3b025d8d241c6@haskell.org> References: <044.d03a5005166332b97ad3b025d8d241c6@haskell.org> Message-ID: <059.dfe9a0551da8e87fcc7b38d35ad485ff@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:39 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:39 -0000

#8320: Build fails due to Haddock error in ghc-prim:GHC.Types ----------------------------------------+--------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by krakrjak): I'm still having this problem and #8276 is solved for me on 64bit Linux. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8320#comment:27 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 22:53:39 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 22:53:39 -0000 Subject: [GHC] #8430: Literate haskell accepts spurious \end{code} lines In-Reply-To: <044.7242a970e3463fe0811ca55e762567c5@haskell.org> References: <044.7242a970e3463fe0811ca55e762567c5@haskell.org> Message-ID: <059.bd972f4a91a60832d14e4e87d74bf83f@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:39 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:39 -0000

#8430: Literate haskell accepts spurious \end{code} lines -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHC accepts | Difficulty: Easy (less than 1 invalid program | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"400c260f977f5cd2bf2f2f26deeeecbe37466295/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="400c260f977f5cd2bf2f2f26deeeecbe37466295" Reject spurious \end{code} in literate mode (#8430) }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8430#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 22:54:32 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 22:54:32 -0000 Subject: [GHC] #8430: Literate haskell accepts spurious \end{code} lines In-Reply-To: <044.7242a970e3463fe0811ca55e762567c5@haskell.org> References: <044.7242a970e3463fe0811ca55e762567c5@haskell.org> Message-ID: <059.20d0145817cf9cb533ee8584db23835e@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:39 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:39 -0000

#8430: Literate haskell accepts spurious \end{code} lines -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHC accepts | Difficulty: Easy (less than 1 invalid program | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"de7b69ec772ac90bdf157b22a789249298a04a2c/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="de7b69ec772ac90bdf157b22a789249298a04a2c" Test #8430 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8430#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 22:55:22 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 22:55:22 -0000 Subject: [GHC] #8430: Literate haskell accepts spurious \end{code} lines In-Reply-To: <044.7242a970e3463fe0811ca55e762567c5@haskell.org> References: <044.7242a970e3463fe0811ca55e762567c5@haskell.org> Message-ID: <059.d052add11dee78a3dcf0a11d17944c84@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:39 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:39 -0000

#8430: Literate haskell accepts spurious \end{code} lines -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHC accepts | Difficulty: Easy (less than 1 invalid program | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => closed * resolution: => fixed Comment: Patch applied, thanks! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8430#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 23:50:44 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 23:50:44 -0000 Subject: [GHC] #8303: defer StackOverflow exceptions (rather than dropping them) when exceptions are masked In-Reply-To: <047.f5c1e98e88fb0e535a65a8bb76dcd836@haskell.org> References: <047.f5c1e98e88fb0e535a65a8bb76dcd836@haskell.org> Message-ID: <062.a12a16a4a6705786a2939bd9105cb14e@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:40 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:40 -0000

#8303: defer StackOverflow exceptions (rather than dropping them) when exceptions are masked -------------------------------+------------------------------------------- Reporter: rwbarton | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime | Version: 7.7 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"c6af06ef38813c460eaa0dec613eae98f4a57796/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c6af06ef38813c460eaa0dec613eae98f4a57796" If exceptions are blocked, add stack overflow to blocked exceptions list. Fixes #8303. Signed-off-by: Edward Z. Yang <ezyang at mit.edu> }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8303#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 23:53:24 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 23:53:24 -0000 Subject: [GHC] #8303: defer StackOverflow exceptions (rather than dropping them) when exceptions are masked In-Reply-To: <047.f5c1e98e88fb0e535a65a8bb76dcd836@haskell.org> References: <047.f5c1e98e88fb0e535a65a8bb76dcd836@haskell.org> Message-ID: <062.eac679f48ca315d36fb451514701217d@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:40 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:40 -0000

#8303: defer StackOverflow exceptions (rather than dropping them) when exceptions are masked -------------------------------+------------------------------------------- Reporter: rwbarton | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime | Version: 7.7 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by ezyang): Hey Reid, I wanted to use your test case, but its use of /dev/null makes it not portable. Can you fix that? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8303#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Fri Oct 11 23:58:36 2013 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Oct 2013 23:58:36 -0000 Subject: [GHC] #8303: defer StackOverflow exceptions (rather than dropping them) when exceptions are masked In-Reply-To: <047.f5c1e98e88fb0e535a65a8bb76dcd836@haskell.org> References: <047.f5c1e98e88fb0e535a65a8bb76dcd836@haskell.org> Message-ID: <062.91d6cddfe36118c8fea63e27a136e6a7@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:40 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:40 -0000

#8303: defer StackOverflow exceptions (rather than dropping them) when exceptions are masked -------------------------------+------------------------------------------- Reporter: rwbarton | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime | Version: 7.7 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by rwbarton):

Hey Reid, I wanted to use your test case, but its use of /dev/null makes it not portable.

Does it really? I figured it would be okay since I noticed the testsuite driver redirected stdin from `/dev/null` anyways... does it do something different on Windows?

Can you fix that?

Hmm, maybe. I guess since I set the max stack size so low, I can reduce `bignum` to something like 500, set `ignore_output`, and have the failure mode of the test be that the program completes successfully... I'll try it. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8303#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 12 00:08:33 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Oct 2013 00:08:33 -0000 Subject: [GHC] #8303: defer StackOverflow exceptions (rather than dropping them) when exceptions are masked In-Reply-To: <047.f5c1e98e88fb0e535a65a8bb76dcd836@haskell.org> References: <047.f5c1e98e88fb0e535a65a8bb76dcd836@haskell.org> Message-ID: <062.f9dcaff805876b362c18e96d39fac0e7@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:40 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:40 -0000

#8303: defer StackOverflow exceptions (rather than dropping them) when exceptions are masked -------------------------------+------------------------------------------- Reporter: rwbarton | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime | Version: 7.7 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by ezyang): I believe the situation is that msys will provide `/dev/null`, but MingW compiled things will not. I can pull it up on my Windows box and test it out if you like. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8303#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 12 00:09:26 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Oct 2013 00:09:26 -0000 Subject: [GHC] #8310: Can we change the semantics of `Trustworthy`? In-Reply-To: <045.91a9ef38d8b695a957254547374ae4ed@haskell.org> References: <045.91a9ef38d8b695a957254547374ae4ed@haskell.org> Message-ID: <060.2d661f3cf30cc942bad4be430d0a70df@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:40 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:40 -0000

#8310: Can we change the semantics of `Trustworthy`? -------------------------------------+------------------------------------ Reporter: ekmett | Owner: dterei Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by monoidal): @dterei: Sorry for nagging, but do you have any update regarding this? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8310#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 12 00:25:50 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Oct 2013 00:25:50 -0000 Subject: [GHC] #8429: GHC.Base.{breakpoint, breakpointCond} do nothing In-Reply-To: <045.4c9eb90270eb503495dbeb412abc60e7@haskell.org> References: <045.4c9eb90270eb503495dbeb412abc60e7@haskell.org> Message-ID: <060.debcfe7b22794b3db27e94f56ea692e4@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:40 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:40 -0000

Replying to [comment:3 simonmar]:

...

Would someone like to go ahead and remove them?

Would it be possible to make them work again? I'm willing to write a

#8429: GHC.Base.{breakpoint, breakpointCond} do nothing -------------------------------------+------------------------------------ Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 1377 -------------------------------------+------------------------------------ Comment (by ntc2): Replying to [comment:4 refold]: patch if someone gives me advice on where to start. That would be great! I've summarized some workarounds [http://stackoverflow.com/questions/19283911/how-do-i-use-ghc-exts- breakpoint/19304091#19304091 here], but they're not very good. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8429#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 12 01:15:09 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Oct 2013 01:15:09 -0000 Subject: [GHC] #8437: pprCallishMachOp_for_C: MO_Prefetch_Data 0 not supported In-Reply-To: <044.b8f976d3fed1b8312bbd200602ccf39f@haskell.org> References: <044.b8f976d3fed1b8312bbd200602ccf39f@haskell.org> Message-ID: <059.8021c61f18e5822a760070339c2659b8@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:41 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:41 -0000

#8437: pprCallishMachOp_for_C: MO_Prefetch_Data 0 not supported -------------------------------------+----------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+----------------------------- Comment (by Erik de Castro Lopo ): In [changeset:"896cee02e766c687a52cd75382bcfed64a623619/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="896cee02e766c687a52cd75382bcfed64a623619" Make MO_Prefetch_Data a no-op in the C backend (#8437). Signed-off-by: Erik de Castro Lopo <erikd at mega-nerd.com> }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8437#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 12 02:11:42 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Oct 2013 02:11:42 -0000 Subject: [GHC] #8422: type nats solver is too weak! In-Reply-To: <045.a8bed5de254996d75b3b1116e9b1eced@haskell.org> References: <045.a8bed5de254996d75b3b1116e9b1eced@haskell.org> Message-ID: <060.b281e5848d83fe4042094696b88262c6@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:41 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:41 -0000

#8422: type nats solver is too weak! ----------------------------------------------+---------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by thoughtpolice): * cc: diatchki (added) * priority: highest => normal * milestone: 7.8.1 => 7.10.1 Comment: This shouldn't be highest priority. The example is the status report isn't literal. The solver works as expected if you give it terms to think about, but perhaps it should be reworded. If you have a problem with something this simple, we need an example. But the core problem with your example is that the solver doesn't recognize that `+` is associative, as Richard pointed out in #8423 (but you can get around this with a manual proof term defined inductively. at least.) For example, I believe `plus_succ` here should typecheck without issue. In any case, this probably won't be solved in the 7.8 timeframe, but I've added Iavor to the ticket in case he wants to correct me or clarify something. {{{#!haskell {-# LANGUAGE DataKinds, TypeOperators #-} module Main where import GHC.TypeLits import Data.Proxy import Data.Type.Equality witness1 :: Proxy x -> Proxy (x+2) witness1 _ = Proxy -- This typechecks ex1 :: Proxy 5 ex1 = witness1 (Proxy :: Proxy 3) -- This does not --ex2 :: Proxy 5 --ex2 = witness1 (Proxy :: Proxy 4) -------------------------------------------------------------------------------- -- Proof of zero identity plus_id :: Proxy n -> (n+0 :~: n) plus_id _ = Refl -- Proof of associativity -- -- This doesn't typecheck --plus_succ :: Proxy n1 -> Proxy n2 -> (n1+(n2+1) :~: (n1+n2)+1) --plus_succ _ _ = Refl }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8422#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 12 02:19:21 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Oct 2013 02:19:21 -0000 Subject: [GHC] #8431: ghci freezes in multiline when passed a closing paren In-Reply-To: <044.fc0b13a44f809091529a93c8522bae49@haskell.org> References: <044.fc0b13a44f809091529a93c8522bae49@haskell.org> Message-ID: <059.ed8c8339f19b896d2a5f308929975525@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:41 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:41 -0000

#8431: ghci freezes in multiline when passed a closing paren -------------------------------+------------------------------------------- Reporter: errge | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------+------------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"6c122f9c8850df6b6869af17cf7420e7da5c3270/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6c122f9c8850df6b6869af17cf7420e7da5c3270" Fix freezing on bare ')' with alternative layout rule (#8431) Patch by errge }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8431#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 12 02:56:42 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Oct 2013 02:56:42 -0000 Subject: [GHC] #8279: bad alignment in code gen yields substantial perf issue In-Reply-To: <045.3fa2c6fed8a76bf664b09b6a4e78beae@haskell.org> References: <045.3fa2c6fed8a76bf664b09b6a4e78beae@haskell.org> Message-ID: <060.5c431fd09a6fc176a9c50606c2d3f249@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:41 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:41 -0000

#8279: bad alignment in code gen yields substantial perf issue --------------------------------------------+------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8082 --------------------------------------------+------------------------------ Changes (by thoughtpolice): * priority: highest => high * milestone: => 7.10.1 Comment: I'm de-escalating this and punting it to 7.10. There's no reason it should be highest priority IMO. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8279#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 12 03:01:11 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Oct 2013 03:01:11 -0000 Subject: [GHC] #8431: ghci freezes in multiline when passed a closing paren In-Reply-To: <044.fc0b13a44f809091529a93c8522bae49@haskell.org> References: <044.fc0b13a44f809091529a93c8522bae49@haskell.org> Message-ID: <059.0922b319c34b3ebfb2ac58f17aa090a6@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:41 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:41 -0000

#8431: ghci freezes in multiline when passed a closing paren -------------------------------+------------------------------------------- Reporter: errge | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------+------------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"c4c640ecc2478143c4a31fd0ed28c06af4bb7b8a/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="c4c640ecc2478143c4a31fd0ed28c06af4bb7b8a" Test #8431 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8431#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 12 03:01:53 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Oct 2013 03:01:53 -0000 Subject: [GHC] #8412: TH allows negative type-level integers In-Reply-To: <047.68a9bececbb7f0d86cec5b7c41950825@haskell.org> References: <047.68a9bececbb7f0d86cec5b7c41950825@haskell.org> Message-ID: <062.305d46d4fa6f1df06da0a471bca55930@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:41 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:41 -0000

#8412: TH allows negative type-level integers -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHC accepts | Difficulty: Easy (less than 1 invalid program | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by thoughtpolice): Krzysztof, this patch looks good to me. Feel free to merge when you have time. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8412#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 12 03:01:58 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Oct 2013 03:01:58 -0000 Subject: [GHC] #8301: error BaseReg must be in a register for THREADED_RTS In-Reply-To: <044.0651fb01dd71f2601e90f46aa455c558@haskell.org> References: <044.0651fb01dd71f2601e90f46aa455c558@haskell.org> Message-ID: <059.25be2f055e68acbc9bcb3b885e8aba34@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:41 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:41 -0000

#8301: error BaseReg must be in a register for THREADED_RTS ----------------------------------------+----------------------------- Reporter: erikd | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by erikd): The root of this problem is the following error assertion: {{{ #if defined(THREADED_RTS) && !defined(NOSMP) #error BaseReg must be in a register for THREADED_RTS #endif }}} which then causes a cascade of undefined identifier errors. The fix is to come up with a valid way to define `BaseReg` for this case. Unfortunately how to do that is not obvious to me at the moment. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8301#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 12 03:02:40 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Oct 2013 03:02:40 -0000 Subject: [GHC] #8434: dynflag dependency addition in TcRnDriver is not needed anymore In-Reply-To: <044.18b1fa8e0bffb7cf60a63e5a38f86534@haskell.org> References: <044.18b1fa8e0bffb7cf60a63e5a38f86534@haskell.org> Message-ID: <059.36e2c95fd76d14d9902bef480102ee12@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:41 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:41 -0000

#8434: dynflag dependency addition in TcRnDriver is not needed anymore -------------------------------+------------------------------------------- Reporter: errge | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------+------------------------------------------- Comment (by thoughtpolice): LGTM. On my queue... -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8434#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 12 03:02:55 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Oct 2013 03:02:55 -0000 Subject: [GHC] #8435: Do not copy stack after stack overflow In-Reply-To: <045.54f81ed32448cf035819222e39f1dbaf@haskell.org> References: <045.54f81ed32448cf035819222e39f1dbaf@haskell.org> Message-ID: <060.128ca4dc3351313b21e51e381b06042f@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:41 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:41 -0000

#8435: Do not copy stack after stack overflow --------------------------------------------+------------------------------ Reporter: ezyang | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Edward Z. Yang ): In [changeset:"9fb30cbcbc02086c5c6eb3942acdfdcad8331cb9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9fb30cbcbc02086c5c6eb3942acdfdcad8331cb9" Do not copy stack after stack overflow, fixes #8435 Signed-off-by: Edward Z. Yang <ezyang at mit.edu> }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8435#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 12 03:03:24 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Oct 2013 03:03:24 -0000 Subject: [GHC] #8435: Do not copy stack after stack overflow In-Reply-To: <045.54f81ed32448cf035819222e39f1dbaf@haskell.org> References: <045.54f81ed32448cf035819222e39f1dbaf@haskell.org> Message-ID: <060.8ea72d23befb07e91db6ba80d1fa66a6@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:41 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:41 -0000

#8435: Do not copy stack after stack overflow --------------------------------------------+------------------------------ Reporter: ezyang | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by ezyang): * status: new => closed * resolution: => fixed -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8435#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 12 03:06:20 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Oct 2013 03:06:20 -0000 Subject: [GHC] #8431: ghci freezes in multiline when passed a closing paren In-Reply-To: <044.fc0b13a44f809091529a93c8522bae49@haskell.org> References: <044.fc0b13a44f809091529a93c8522bae49@haskell.org> Message-ID: <059.98c80a2acea3b4db4883bae2e9f43d76@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:41 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:41 -0000

#8431: ghci freezes in multiline when passed a closing paren -------------------------------+------------------------------------------- Reporter: errge | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------+------------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"1d09d7462fe8fffa41e1ddf29fec53b031928d62/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="1d09d7462fe8fffa41e1ddf29fec53b031928d62" Add a timeout for #8431 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8431#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 12 03:07:30 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Oct 2013 03:07:30 -0000 Subject: [GHC] #8431: ghci freezes in multiline when passed a closing paren In-Reply-To: <044.fc0b13a44f809091529a93c8522bae49@haskell.org> References: <044.fc0b13a44f809091529a93c8522bae49@haskell.org> Message-ID: <059.928f5799412382be1f4e923e4c2ac54d@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:42 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:42 -0000

#8431: ghci freezes in multiline when passed a closing paren -------------------------------+------------------------------------------- Reporter: errge | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------+------------------------------------------- Changes (by monoidal): * status: patch => closed * resolution: => fixed Comment: I applied the patch - thanks. hvr: The bug could indeed be triggered with a single-character file ')' and the flag `-XAlternativeLayoutRule`. The patch fixed it. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8431#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 12 03:09:12 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Oct 2013 03:09:12 -0000 Subject: [GHC] #7685: :script command does not resolve ~ In-Reply-To: <046.cb641c7d9e463a4d3ab2a24ca4b94786@haskell.org> References: <046.cb641c7d9e463a4d3ab2a24ca4b94786@haskell.org> Message-ID: <061.a82b8c7192aec9963b40533878a601eb@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:42 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:42 -0000

#7685: :script command does not resolve ~ -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.6.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7685#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 12 03:17:54 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Oct 2013 03:17:54 -0000 Subject: [GHC] #8397: reify annotations in TH In-Reply-To: <044.a4a47bd65a3e3433fc8157425376cea6@haskell.org> References: <044.a4a47bd65a3e3433fc8157425376cea6@haskell.org> Message-ID: <059.f5e2c03969e2cfef781f7af77933c056@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:42 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:42 -0000

#8397: reify annotations in TH -------------------------------+------------------------------------------- Reporter: errge | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: 7867 | -------------------------------+------------------------------------------- Comment (by thoughtpolice): This patch looks good to me (#8398 needs more attention, as discussed in TemplateHaskell/Annotations) - on my queue. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8397#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 12 03:43:23 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Oct 2013 03:43:23 -0000 Subject: [GHC] #8438: Validation failure compiling primitive-memops.c Message-ID: <047.531102d80c106049f501fc03b8c458e2@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:42 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:42 -0000

From ghc-devs at haskell.org Sat Oct 12 03:48:49 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Oct 2013 03:48:49 -0000 Subject: [GHC] #8439: add a CPP program field to Settings file (decouple CPP

#8438: Validation failure compiling primitive-memops.c ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When I try to validate a clean checkout of HEAD, I see this: {{{ "inplace/bin/ghc-stage2" -optc-Werror -optc-Wall -optc- Ilibraries/primitive/cbits -optc-O3 -optc-ftree-vectorize -optc-fomit- frame-pointer -optc-msse2 -optc-I'/Users/rae/Documents/ghc- cur/libraries/base/include' -optc-I'/Users/rae/Documents/ghc- cur/rts/dist/build' -optc-I'/Users/rae/Documents/ghc-cur/includes' -optc-I'/Users/rae/Documents/ghc-cur/includes/dist- derivedconstants/header' -static -H32m -O -Werror -Wall -H64m -O0 -package-name primitive-0.5.1.0 -hide-all-packages -i -ilibraries/primitive/. -ilibraries/primitive/dist-install/build -ilibraries/primitive/dist-install/build/autogen -Ilibraries/primitive /dist-install/build -Ilibraries/primitive/dist-install/build/autogen -Ilibraries/primitive/cbits -optP-include -optPlibraries/primitive /dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package ghc-prim-0.3.1.0 -O2 -Wall -XHaskell2010 -O2 -O -dcore-lint -fno-warn-amp -fno-warn-deprecated-flags -no-user-package-db -rtsopts -Wwarn -c libraries/primitive/cbits/primitive-memops.c -o libraries/primitive/dist- install/build/cbits/primitive-memops.o cc1: warnings being treated as errors libraries/primitive/cbits/primitive-memops.c: In function ?hsprimitive_memset_Word16?: libraries/primitive/cbits/primitive-memops.c:44:0: warning: dereferencing type-punned pointer will break strict-aliasing rules libraries/primitive/cbits/primitive-memops.c: In function ?hsprimitive_memset_Word32?: libraries/primitive/cbits/primitive-memops.c:45:0: warning: dereferencing type-punned pointer will break strict-aliasing rules libraries/primitive/cbits/primitive-memops.c: In function ?hsprimitive_memset_Word64?: libraries/primitive/cbits/primitive-memops.c:46:0: warning: dereferencing type-punned pointer will break strict-aliasing rules libraries/primitive/cbits/primitive-memops.c: In function ?hsprimitive_memset_Word?: libraries/primitive/cbits/primitive-memops.c:47:0: warning: dereferencing type-punned pointer will break strict-aliasing rules libraries/primitive/cbits/primitive-memops.c: In function ?hsprimitive_memset_Ptr?: libraries/primitive/cbits/primitive-memops.c:48:0: warning: dereferencing type-punned pointer will break strict-aliasing rules libraries/primitive/cbits/primitive-memops.c: In function ?hsprimitive_memset_Float?: libraries/primitive/cbits/primitive-memops.c:49:0: warning: dereferencing type-punned pointer will break strict-aliasing rules libraries/primitive/cbits/primitive-memops.c: In function ?hsprimitive_memset_Double?: libraries/primitive/cbits/primitive-memops.c:50:0: warning: dereferencing type-punned pointer will break strict-aliasing rules make[1]: *** [libraries/primitive/dist-install/build/cbits/primitive- memops.o] Error 1 make: *** [all] Error 2 }}} I run Mac OS 10.7.5 with XCode 4.3.3. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8438 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler program and C compiler choice) Message-ID: <045.b102c8aef525c2e2e4e30540ff75513b@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:42 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:42 -0000 #8439: add a CPP program field to Settings file (decouple CPP program and C compiler choice) ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- the tight coupling in a vanilla GHC between the choice of c compiler and CPP program (for the normal user, with or without cabal-install managing the build) is a huge source of support problems for GHC on OS X right now. Additionally, even if everyone started having cpphs or something similar installed on their computers tomorrow, we have no way of bundling it with GHC so that it will be called by default for any Haskell CPP needs. accordingly, maybe it'd be worth adding a cpp program field to settings? i'm aware of -pgmP and how cabal can use it (or I can), but normal ghc packages and naive end users don't twiddle that. also its been said a number of times recently that GHC should have its own preprocessor, and if so, we need to bake in machinery to be able to distribute a program distinct from the C compiler for that role -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8439 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 12 03:49:27 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Oct 2013 03:49:27 -0000 Subject: [GHC] #8425: ghc-7.6.3: crossmodule inline leads to buggy code (-O2) In-Reply-To: <045.a29452ea9fbac42eef37cbddc5ab6d06@haskell.org> References: <045.a29452ea9fbac42eef37cbddc5ab6d06@haskell.org> Message-ID: <060.feaf8838524968a6c331866d8cfb93b8@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:42 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:42 -0000

#8425: ghc-7.6.3: crossmodule inline leads to buggy code (-O2) -------------------------------------+---------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by slyfox): * status: new => closed * resolution: => fixed Comment: As noted by monoidal in irc the nature of error points to strictness analyzer (like in bug #7737) Looks like changeset:0831a12ea2fc73c33652eeec1adc79fa19700578 and later changed the logic substantially, thus there is no simple thing for me to try to pull into 7.6 branch to test the theory. Marking as fixed. Maybe, tests is worth pulling in the test suite (it's a bit big though). Sorry for the noise. Thanks! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8425#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 12 05:53:41 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Oct 2013 05:53:41 -0000 Subject: [GHC] #7774: T5313 fails In-Reply-To: <044.269de52e286e977138cf795af4626d88@haskell.org> References: <044.269de52e286e977138cf795af4626d88@haskell.org> Message-ID: <059.d17b41e9808ab53cdd822ee28f46559b@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:43 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:43 -0000

#7774: T5313 fails -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: GHC API | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thoughtpolice): I'm seeing this test pass now on amd64/linux. Geoff, can you confirm? What platform? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7774#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 12 05:54:40 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Oct 2013 05:54:40 -0000 Subject: [GHC] #8434: dynflag dependency addition in TcRnDriver is not needed anymore In-Reply-To: <044.18b1fa8e0bffb7cf60a63e5a38f86534@haskell.org> References: <044.18b1fa8e0bffb7cf60a63e5a38f86534@haskell.org> Message-ID: <059.c8f0bdd27add7a218e8ece4521997896@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:43 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:43 -0000

#8434: dynflag dependency addition in TcRnDriver is not needed anymore -------------------------------+------------------------------------------- Reporter: errge | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------+------------------------------------------- Comment (by Austin Seipp ): In [changeset:"eafae362ddc838245b3a50e1fb039cb6f211f801/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="eafae362ddc838245b3a50e1fb039cb6f211f801" Remove outdated comment (#8434) Authored-by: Gergely Risko <gergely at risko.hu> Signed-off-by: Austin Seipp <austin at well-typed.com> }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8434#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 12 05:54:41 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Oct 2013 05:54:41 -0000 Subject: [GHC] #8397: reify annotations in TH In-Reply-To: <044.a4a47bd65a3e3433fc8157425376cea6@haskell.org> References: <044.a4a47bd65a3e3433fc8157425376cea6@haskell.org> Message-ID: <059.fe7d30be118db854cef592741dc95e56@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:43 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:43 -0000

#8397: reify annotations in TH -------------------------------+------------------------------------------- Reporter: errge | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: 7867 | -------------------------------+------------------------------------------- Comment (by Austin Seipp ): In [changeset:"7186bdb1007cce27bf98ec9d96c9fe1d07099f0b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7186bdb1007cce27bf98ec9d96c9fe1d07099f0b" Add machinery to reify annotations (#8397) Authored-by: Gergely Risko <gergely at risko.hu> Signed-off-by: Austin Seipp <austin at well-typed.com> }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8397#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 12 05:54:41 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Oct 2013 05:54:41 -0000 Subject: [GHC] #8139: ghc 7.6.3 and ghc HEAD fails to build on OS X 10.9 In-Reply-To: <052.92009bd3b6836bd26916c16cd983224b@haskell.org> References: <052.92009bd3b6836bd26916c16cd983224b@haskell.org> Message-ID: <067.a1a03e4995ab7de000f878e1e6ef5ae5@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:43 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:43 -0000

#8139: ghc 7.6.3 and ghc HEAD fails to build on OS X 10.9 -------------------------------------+------------------------------------- Reporter: darinmorrison | Owner: darinmorrison Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"feb76385b6eb88ceb8c3bd0a21d9723a607e2944/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="feb76385b6eb88ceb8c3bd0a21d9723a607e2944" Fix mkdirhier.sh on OS X 10.9 (#8139) Mac OS X 10.9 mkdir is apparently stricter than the Mac OS X 10.8 mkdir about which paths are considered valid arguments. For example, in a typical build on Mac OS X 10.9, the first of the following invocations of mkdirhier.sh will succeed but the second will fail: "inplace/bin/mkdirhier" utils/ghc-cabal/dist/build/tmp//. # WORKS "inplace/bin/mkdirhier" bootstrapping/. # FAILS Simply prefixing the path arguments with "./" causes both to succeed: "inplace/bin/mkdirhier" ./utils/ghc-cabal/dist/build/tmp//. # WORKS "inplace/bin/mkdirhier" ./bootstrapping/. # WORKS Testing indicates failure on paths satisfying all of these criteria: - path is suffixed with "/." - path is only 1 level deep (e.g., "foo/."; _not_ "foo/bar/.") - path is _not_ prefixed with "./" This workaround prefixes "./" to the path argument passed to mkdir. Signed-off-by: Austin Seipp <austin at well-typed.com> }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8139#comment:19 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 12 05:54:41 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Oct 2013 05:54:41 -0000 Subject: [GHC] #8139: ghc 7.6.3 and ghc HEAD fails to build on OS X 10.9 In-Reply-To: <052.92009bd3b6836bd26916c16cd983224b@haskell.org> References: <052.92009bd3b6836bd26916c16cd983224b@haskell.org> Message-ID: <067.d90c1125f4d93c4b5af960e4242ef2b4@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:43 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:43 -0000

#8139: ghc 7.6.3 and ghc HEAD fails to build on OS X 10.9 -------------------------------------+------------------------------------- Reporter: darinmorrison | Owner: darinmorrison Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"8878541d02ad15fbdbd04608cbc6ea3fde5d5beb/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8878541d02ad15fbdbd04608cbc6ea3fde5d5beb" Fix building RtsProbes.d on Mac OS X 10.9 (#8139) Signed-off-by: Austin Seipp <austin at well-typed.com> }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8139#comment:20 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 12 05:56:03 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Oct 2013 05:56:03 -0000 Subject: [GHC] #8432: clarify throwTo documentation In-Reply-To: <044.343104dcd600c3cb51a2aebd4a3eab5b@haskell.org> References: <044.343104dcd600c3cb51a2aebd4a3eab5b@haskell.org> Message-ID: <059.244f5f9f1e1c5f64a80ddfe46e7f7ef8@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:43 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:43 -0000

#8432: clarify throwTo documentation -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Documentation | Difficulty: Easy (less than 1 bug | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"3782a25f36a21b2dbee62dcb0029eb2302abf2f7/base"]: {{{ #!CommitTicketReference repository="base" revision="3782a25f36a21b2dbee62dcb0029eb2302abf2f7" Clarify docs for throwTo wrt atomicity (#8432) Authored-by: Bertram Felgenhauer Signed-off-by: Austin Seipp <aseipp at pobox.com> }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8432#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 12 05:56:03 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Oct 2013 05:56:03 -0000 Subject: [GHC] #8307: iOS patch: fix hangs in threaded runtime In-Reply-To: <045.058d96dae0fc0276635a545e44f48b2f@haskell.org> References: <045.058d96dae0fc0276635a545e44f48b2f@haskell.org> Message-ID: <060.eec21f8bb9a410b70b323b91a9ec7321@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:43 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:43 -0000

#8307: iOS patch: fix hangs in threaded runtime -------------------------------+------------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: | Version: 7.7 libraries/base | Keywords: Resolution: | Architecture: arm Operating System: Other | Difficulty: Easy (less than 1 hour) Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by Austin Seipp ): In [changeset:"ff8200afda9b7ada28e1199a109b6b5acf8c30d6/base"]: {{{ #!CommitTicketReference repository="base" revision="ff8200afda9b7ada28e1199a109b6b5acf8c30d6" Fix hangs with -threaded on iOS (#8307) Authored-by: Luke Iannini <lukexi at me.com> Signed-off-by: Austin Seipp <aseipp at pobox.com> }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8307#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 12 05:59:10 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Oct 2013 05:59:10 -0000 Subject: [GHC] #8139: ghc 7.6.3 and ghc HEAD fails to build on OS X 10.9 In-Reply-To: <052.92009bd3b6836bd26916c16cd983224b@haskell.org> References: <052.92009bd3b6836bd26916c16cd983224b@haskell.org> Message-ID: <067.62298256ccb327cfddda10867648b461@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:44 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:44 -0000

#8139: ghc 7.6.3 and ghc HEAD fails to build on OS X 10.9 -------------------------------------+------------------------------------- Reporter: darinmorrison | Owner: darinmorrison Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8139#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 12 05:59:28 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Oct 2013 05:59:28 -0000 Subject: [GHC] #8397: reify annotations in TH In-Reply-To: <044.a4a47bd65a3e3433fc8157425376cea6@haskell.org> References: <044.a4a47bd65a3e3433fc8157425376cea6@haskell.org> Message-ID: <059.03de74177aefb60029c2419ff83c98b7@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:44 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:44 -0000

#8397: reify annotations in TH -------------------------------+------------------------------------------- Reporter: errge | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: 7867 | -------------------------------+------------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8397#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 12 05:59:40 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Oct 2013 05:59:40 -0000 Subject: [GHC] #8307: iOS patch: fix hangs in threaded runtime In-Reply-To: <045.058d96dae0fc0276635a545e44f48b2f@haskell.org> References: <045.058d96dae0fc0276635a545e44f48b2f@haskell.org> Message-ID: <060.92a7f241acf9166c51b92dfadeea0419@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:44 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:44 -0000

#8307: iOS patch: fix hangs in threaded runtime -------------------------------+------------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: | Version: 7.7 libraries/base | Keywords: Resolution: fixed | Architecture: arm Operating System: Other | Difficulty: Easy (less than 1 hour) Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8307#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 12 05:59:52 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Oct 2013 05:59:52 -0000 Subject: [GHC] #8434: dynflag dependency addition in TcRnDriver is not needed anymore In-Reply-To: <044.18b1fa8e0bffb7cf60a63e5a38f86534@haskell.org> References: <044.18b1fa8e0bffb7cf60a63e5a38f86534@haskell.org> Message-ID: <059.fe418ebe61e70e882242effde977bf14@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:44 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:44 -0000

#8434: dynflag dependency addition in TcRnDriver is not needed anymore -------------------------------+------------------------------------------- Reporter: errge | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------+------------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8434#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 12 06:00:01 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Oct 2013 06:00:01 -0000 Subject: [GHC] #8432: clarify throwTo documentation In-Reply-To: <044.343104dcd600c3cb51a2aebd4a3eab5b@haskell.org> References: <044.343104dcd600c3cb51a2aebd4a3eab5b@haskell.org> Message-ID: <059.780f4384775f0b044cc7badbd0b79043@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:44 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:44 -0000

#8432: clarify throwTo documentation -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Documentation | Difficulty: Easy (less than 1 bug | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8432#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 12 06:00:21 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Oct 2013 06:00:21 -0000 Subject: [GHC] #8409: nofib-analyse: compile allocations In-Reply-To: <045.8888a02d96d1846d8871fbe468aa0f72@haskell.org> References: <045.8888a02d96d1846d8871fbe468aa0f72@haskell.org> Message-ID: <060.f8669d522c99d4c34b9b3798f4736b20@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:44 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:44 -0000

#8409: nofib-analyse: compile allocations -------------------------------------+------------------------------------- Reporter: leroux | Owner: leroux Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: NoFib benchmark | Version: 7.6.3 suite | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: None/Unknown | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by thoughtpolice): Merged, thanks! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8409#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 12 06:00:28 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Oct 2013 06:00:28 -0000 Subject: [GHC] #8409: nofib-analyse: compile allocations In-Reply-To: <045.8888a02d96d1846d8871fbe468aa0f72@haskell.org> References: <045.8888a02d96d1846d8871fbe468aa0f72@haskell.org> Message-ID: <060.7712b2202e15687aabc4bc636b02e8b2@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:45 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:45 -0000

#8409: nofib-analyse: compile allocations -------------------------------------+------------------------------------- Reporter: leroux | Owner: leroux Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: NoFib benchmark | Version: 7.6.3 suite | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: None/Unknown | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8409#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

From ghc-devs at haskell.org Sat Oct 12 06:18:19 2013 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Oct 2013 06:18:19 -0000 Subject: [GHC] #8440: Get rid of the remaining static flags Message-ID: <052.744af3e10192bedb98c0b515d9a6cc6d@haskell.org> X-List-Received-Date: Sat, 12 Oct 2013 07:42:45 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:42:45 -0000

#8440: Get rid of the remaining static flags ------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: task | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- On the heels of fixing #8276, we should get rid of the remaining static flags. For the remaining cases, there's no real reason they should be static, other than changing them is fairly invasive and will require some refactoring. I'm making this a goal for 7.10, since we only have 5 flags left (and a lot of the changes for them are overlapping, so fixing one will probably go a ways towards fixing the others.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8440 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler