Re: [GHC] #8301: error BaseReg must be in a register for THREADED_RTS

11 Oct 2013

      #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