Re: [GHC] #2399: Template Haskell: support for view patterns

2008-07-01 Thread GHC
#2399: Template Haskell: support for view patterns
--+-
 Reporter:  fons  |  Owner: 
 Type:  feature request   | Status:  new
 Priority:  low   |  Milestone:  _|_
Component:  Template Haskell  |Version:  6.9
 Severity:  normal| Resolution: 
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  Unknown
   Os:  Unknown   |  
--+-
Comment (by AudreyTang):

 Simon, it's difficult to add a guard there, because a QuasiQuoter accepts
 the pattern-generation function of the form:

 {{{
 quoteExprPat :: String - TH.PatQ
 }}}

 But in TH, Guard is part of Body, so a quasiquoter designated to the PatQ
 side cannot affect the BodyQ side.

 As there seems to be no other Pat constructors that's useful for a
 [$rx|...|] at the pattern side, would you consider accepting a patch that
 adds ViewP for 6.10?

 Cheers,

 Audrey

 (The context for [$rx|...|] is http://hackage.haskell.org/cgi-bin/hackage-
 scripts/package/regexqq btw.)

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2399#comment:3
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #2399: Template Haskell: support for view patterns

2008-07-01 Thread GHC
#2399: Template Haskell: support for view patterns
--+-
 Reporter:  fons  |  Owner: 
 Type:  feature request   | Status:  new
 Priority:  low   |  Milestone:  _|_
Component:  Template Haskell  |Version:  6.9
 Severity:  normal| Resolution: 
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  Unknown
   Os:  Unknown   |  
--+-
Changes (by AudreyTang):

 * cc: [EMAIL PROTECTED] (added)

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2399#comment:4
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #2355: Building NDP fails with GHC panic on x86_64

2008-07-01 Thread GHC
#2355: Building NDP fails with GHC panic on x86_64
---+
 Reporter:  Nolari |  Owner:
 Type:  bug| Status:  closed
 Priority:  normal |  Milestone:
Component:  Compiler   |Version:  6.9   
 Severity:  major  | Resolution:  fixed 
 Keywords:  ndp ghc panic  | Difficulty:  Unknown   
 Testcase: |   Architecture:  x86_64 (amd64)
   Os:  Linux  |  
---+
Changes (by rl):

  * status:  new = closed
  * resolution:  = fixed

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2355#comment:11
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #2399: Template Haskell: support for view patterns

2008-07-01 Thread GHC
#2399: Template Haskell: support for view patterns
--+-
 Reporter:  fons  |  Owner: 
 Type:  feature request   | Status:  new
 Priority:  low   |  Milestone:  _|_
Component:  Template Haskell  |Version:  6.9
 Severity:  normal| Resolution: 
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  Unknown
   Os:  Unknown   |  
--+-
Comment (by simonpj):

 Ah I see. I'd missed the quasiquoter connnection.

 One way to fix this would be to add view patterns to TH.  But it made me
 wonder: why aren't pattern guards compositional?  At the moment they are
 resolutely top-level.  And, as you say, not part of patterns.   But syntax
 aside it would make perfect sense to make them part of a pattern:
 {{{
   pat ::= var |  C pat1 ... patn
|  pat|quals
 }}}
 where `qual` is a pattern-guard qualifier. So (again, syntax aside) you
 could write
 {{{
   f (x | x3) = ...

   g ([y] | Just z - lookup y) = ...
 }}}
 That would push pattern guards into the syntax of patterns.  Now view
 patterns are syntactic sugar:
 {{{
   (exp - pat)   means   (x | pat - exp x)
   where x is fresh
 }}}
 The reverse encoding is also possible
 {{{
   (pat | quals)  means   (f - Just (v1,...,vn))
 where
   (v1,...,vn) are the variables bound by pat
   f pat | quals = Just vs
 }}}

 I'm not sure I'm advocating this (yet!), but I hadn't thought of it before
 so I thought I'd jot it down.

 If TH users agree about just how to beef up patterns, I'm not against
 adding it.  I'm just a bit conscious that view patterns are experimental
 and the more concrete we pour the harder it becomes to change.

 Simon

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2399#comment:5
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #2378: panic: lookupVers1, when standalone deriving Typeable and Data

2008-07-01 Thread GHC
#2378: panic: lookupVers1, when standalone deriving Typeable and Data
---+
 Reporter:  guest  |  Owner:  igloo  
 Type:  merge  | Status:  new
 Priority:  normal |  Milestone: 
Component:  Compiler   |Version:  6.8.3  
 Severity:  normal | Resolution: 
 Keywords: | Difficulty:  Unknown
 Testcase:  deriving/should_compile/T2378  |   Architecture:  x86
   Os:  MacOS X|  
---+
Changes (by simonpj):

  * testcase:  = deriving/should_compile/T2378
  * owner:  simonpj = igloo
  * type:  bug = merge

Comment:

 Added a test for the newtype deriving thing. I was wrong above: the thing
 that is broken is standalone deriving for `Typeable1` of newtype:
 {{{
 newtype T a = ...
 deriving instance Typeable1 T
 }}}

 Also reclassifying as 'merge' so that Ian can keep it on his merge list
 for 6.8.4

 Simon

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2378#comment:5
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #2307: Poor warning for conflicting functional dependencies

2008-07-01 Thread GHC
#2307: Poor warning for conflicting functional dependencies
--+-
 Reporter:  NeilMitchell  |  Owner: 
 Type:  bug   | Status:  new
 Priority:  normal|  Milestone:  6.10 branch
Component:  Compiler  |Version:  6.8.2  
 Severity:  normal| Resolution: 
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  Unknown
   Os:  Unknown   |  
--+-
Changes (by igloo):

  * difficulty:  = Unknown
  * milestone:  = 6.10 branch

Comment:

 Thanks for the report! Here is a minimal testcase:
 {{{
 {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies,
  OverlappingInstances, UndecidableInstances,
 IncoherentInstances,
  FlexibleInstances #-}

 module Foo where

 class C a b c | a - b, a - c
 instance C Int (Maybe String) Float
 instance C Int (Maybe Bool)   Double
 }}}
 With the HEAD:
 {{{
 Proof_default.hs:8:0:
 Functional dependencies conflict between instance declarations:
   instance [incoherent] C Int (Maybe String) Float
 -- Defined at Proof_default.hs:8:0-34
   instance [incoherent] C Int (Maybe Bool) Double
 -- Defined at Proof_default.hs:9:0-35
   instance [incoherent] C Int (Maybe Bool) Double
 -- Defined at Proof_default.hs:9:0-35
 }}}
 Before just nubbing the instances, we should make sure that it's not a bug
 that it is finding the same one multiple times in the first place.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2307#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


[GHC] #2409: Error: symbol `ghczmprim_GHCziUnit_Z0T_closure' is already defined

2008-07-01 Thread GHC
#2409: Error: symbol `ghczmprim_GHCziUnit_Z0T_closure' is already defined
-+--
Reporter:  igloo |   Owner: 
Type:  bug   |  Status:  new
Priority:  normal|   Milestone:  6.10.1 
   Component:  Compiler  | Version:  6.9
Severity:  normal|Keywords: 
  Difficulty:  Unknown   |Testcase: 
Architecture:  Unknown   |  Os:  Unknown
-+--
 This module:
 {{{
 module Foo where

 f :: Int - Int
 f _ | () `seq` False = undefined
 | otherwise = error XXX

 g :: Int - Int
 g _ | () `seq` False = undefined
 | otherwise = error XXX
 }}}
 doesn't compile with 6.8.3 or the HEAD; here's what happens with the HEAD
 (compiled with -DDEBUG, but I'm pretty sure it wouldn't work anyway):
 {{{
 $ ghc -fforce-recomp -c Foo.hs
 ghc-6.9.20080701: panic! (the 'impossible' happened)
   (GHC version 6.9.20080701 for x86_64-unknown-linux):
 ASSERT failed! file stgSyn/CoreToStg.lhs line 922 (){v 71} [lid]

 Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

 $ ghc -fforce-recomp -c Foo.hs -O
 /tmp/ghc4665_0/ghc4665_0.s: Assembler messages:

 /tmp/ghc4665_0/ghc4665_0.s:95:0:
  Error: symbol `ghczmprim_GHCziUnit_Z0T_closure' is already defined
 }}}
 The original problem report, using Takusen, is here:
 http://www.haskell.org/pipermail/glasgow-haskell-
 users/2008-June/015037.html

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2409
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


[GHC] #2410: HEAD build fails when building way=p with WAY_p_OPTS='-prof -caf-all -auto-all'

2008-07-01 Thread GHC
#2410: HEAD build fails when building way=p with WAY_p_OPTS='-prof -caf-all 
-auto-
all'
---+
Reporter:  pgavin  |   Owner:  
Type:  bug |  Status:  new 
Priority:  normal  |   Component:  Compiler
 Version:  6.9 |Severity:  normal  
Keywords:  |Testcase:  
Architecture:  x86 |  Os:  MacOS X 
---+
 Specifically, the failure happens while compiling
 libraries/base/Data/Complex.hs:

 -- compiler output 
 /Users/pgavin/local/ghc-6.9/src/ghc-6.9/compiler/stage1/ghc-inplace
 -package-name base-3.0 -hide-all-packages -split-objs -i -idist/build -i.
 -idist/build/autogen -Idist/build -Iinclude -#include HsBase.h -odir
 dist/build -hidir dist/build -stubdir dist/build -package ghc-prim-0.1
 -package integer-0.1 -package rts-1.0 -O -package-name base -XMagicHash
 -XExistentialQuantification -XRank2Types -XScopedTypeVariables
 -XUnboxedTuples -XForeignFunctionInterface -XUnliftedFFITypes
 -XDeriveDataTypeable -XGeneralizedNewtypeDeriving -XFlexibleInstances
 -XPatternSignatures -XStandaloneDeriving -XPatternGuards -XCPP
 -idist/build  -prof -caf-all -auto-all -hisuf p_hi -hcsuf p_hc -osuf p_o
 -H32m -O -H32m -O2 -O2 -Rghc-timing -XGenerics -O2 -Wall -fno-warn-
 deprecated-flags -w  -c Data/Complex.hs -o dist/build/Data/Complex.p_o
 -ohi dist/build/Data/Complex.p_hi

 
/var/folders/o2/o2fca1ekG9SKEu61XaHsjE+++TI/-Tmp-/ghc51695_0/ghc51695_0.split__108.s:1256:0:
 FATAL:Symbol _base_DataziComplex_zeze_CAF_cc_ccs already defined.
 ---

 Compilation succeeds if the SPECIALIZE pragmas are removed from the
 instance declarations for Num, Fractional, and Floating.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2410
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #2366: ASSERT failed! file typecheck/TcMType.lhs line 517

2008-07-01 Thread GHC
#2366: ASSERT failed! file typecheck/TcMType.lhs line 517
+---
 Reporter:  batterseapower  |  Owner: 
 Type:  bug | Status:  new
 Priority:  normal  |  Milestone:  6.10.1 
Component:  Compiler|Version:  6.9
 Severity:  normal  | Resolution: 
 Keywords:  | Difficulty:  Unknown
 Testcase:  gadt/equal  |   Architecture:  Unknown
   Os:  Multiple|  
+---
Changes (by igloo):

  * difficulty:  = Unknown
  * os:  MacOS X = Multiple
  * milestone:  = 6.10.1

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2366#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #2366: ASSERT failed! file typecheck/TcMType.lhs line 517

2008-07-01 Thread GHC
#2366: ASSERT failed! file typecheck/TcMType.lhs line 517
+---
 Reporter:  batterseapower  |  Owner: 
 Type:  bug | Status:  new
 Priority:  normal  |  Milestone:  6.10.1 
Component:  Compiler|Version:  6.9
 Severity:  normal  | Resolution: 
 Keywords:  | Difficulty:  Unknown
 Testcase:  gadt/equal  |   Architecture:  Unknown
   Os:  Multiple|  
+---
Comment (by igloo):

 This is reproducible with `./validate --slow`.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2366#comment:2
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #2368: ASSERT failed! file coreSyn/CorePrep.lhs line 669

2008-07-01 Thread GHC
#2368: ASSERT failed! file coreSyn/CorePrep.lhs line 669
---+
 Reporter:  batterseapower |  Owner: 
 Type:  bug| Status:  new
 Priority:  normal |  Milestone:  6.10.1 
Component:  Compiler   |Version:  6.9
 Severity:  normal | Resolution: 
 Keywords: | Difficulty:  Unknown
 Testcase:  simplCore/should_compile/simpl014  |   Architecture:  Unknown
   Os:  MacOS X|  
---+
Changes (by igloo):

  * difficulty:  = Unknown
  * milestone:  = 6.10.1

Comment:

 This is reproducible with `./validate --slow`.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2368#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #2367: ASSERT failed! file basicTypes/MkId.lhs line 643

2008-07-01 Thread GHC
#2367: ASSERT failed! file basicTypes/MkId.lhs line 643
+---
 Reporter:  batterseapower  |  Owner: 
 Type:  bug | Status:  new
 Priority:  normal  |  Milestone:  6.10.1 
Component:  Compiler|Version:  6.9
 Severity:  normal  | Resolution: 
 Keywords:  | Difficulty:  Unknown
 Testcase:  gadt/records|   Architecture:  Unknown
   Os:  MacOS X |  
+---
Changes (by igloo):

  * difficulty:  = Unknown
  * milestone:  = 6.10.1

Comment:

 I can't reproduce this with `./validate --slow`; did someone fix it?

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2367#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #2307: Poor warning for conflicting functional dependencies

2008-07-01 Thread GHC
#2307: Poor warning for conflicting functional dependencies
-+--
 Reporter:  NeilMitchell |  Owner: 
 Type:  bug  | Status:  closed 
 Priority:  normal   |  Milestone:  6.10 branch
Component:  Compiler |Version:  6.8.2  
 Severity:  normal   | Resolution:  fixed  
 Keywords:   | Difficulty:  Unknown
 Testcase:  typecheck/should_fail/T2307  |   Architecture:  Unknown
   Os:  Unknown  |  
-+--
Changes (by simonpj):

  * testcase:  = typecheck/should_fail/T2307
  * status:  new = closed
  * resolution:  = fixed

Comment:

 Excellent, thanks for refining the test case.  That made it easy.

 In fact, nubbing is the right thing, because `FunDeps.badFunDeps` looks
 through the fundeps one by one; in this case there are two, and the same
 instance conflicts with both.

 Fixed by
 {{{
 Tue Jul  1 17:58:30 BST 2008  [EMAIL PROTECTED]
   * Fix Trac #2307: need to nub bad fundep reports
 }}}
 Simon

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2307#comment:2
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #2376: GHC.Word: shiftR and shiftL are not marked as inline.

2008-07-01 Thread GHC
#2376: GHC.Word: shiftR and shiftL are not marked as inline.
--+-
 Reporter:  mjark |  Owner: 
 Type:  bug   | Status:  new
 Priority:  normal|  Milestone:  6.10.1 
Component:  libraries/base|Version:  6.8.2  
 Severity:  normal| Resolution: 
 Keywords:  inline shiftR shiftL  | Difficulty:  Unknown
 Testcase:|   Architecture:  Unknown
   Os:  Unknown   |  
--+-
Changes (by igloo):

  * difficulty:  = Unknown
  * milestone:  = 6.10.1

Comment:

 Thanks for the report

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2376#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #2373: Build fails to pass locations of external tools to libraries

2008-07-01 Thread GHC
#2373: Build fails to pass locations of external tools to libraries
--+-
 Reporter:  bos   |  Owner:  igloo  
 Type:  bug   | Status:  new
 Priority:  normal|  Milestone:  6.10.1 
Component:  Compiler  |Version:  6.8.2  
 Severity:  normal| Resolution: 
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  Unknown
   Os:  Unknown   |  
--+-
Changes (by igloo):

  * owner:  = igloo
  * difficulty:  = Unknown
  * milestone:  = 6.10.1

Comment:

 Agreed; thanks for the report

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2373#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #2369: tcrun007: Can't find interface-file declaration for variable ....

2008-07-01 Thread GHC
#2369: tcrun007: Can't find interface-file declaration for variable 
-+--
 Reporter:  batterseapower   |  Owner: 
 Type:  bug  | Status:  closed 
 Priority:  normal   |  Milestone: 
Component:  Compiler |Version:  6.9
 Severity:  normal   | Resolution:  invalid
 Keywords:   | Difficulty:  Unknown
 Testcase:  typechecker/should_run/tcrun007  |   Architecture:  Unknown
   Os:  Unknown  |  
-+--
Changes (by igloo):

  * status:  new = closed
  * difficulty:  = Unknown
  * resolution:  = invalid

Comment:

 That's expected; the devel2 build settings don't build the libraries with
 `-XGenerics`, which this test relies upon.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2369#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #2307: Poor warning for conflicting functional dependencies

2008-07-01 Thread GHC
#2307: Poor warning for conflicting functional dependencies
-+--
 Reporter:  NeilMitchell |  Owner:  
 Type:  bug  | Status:  reopened
 Priority:  normal   |  Milestone:  6.10.1  
Component:  Compiler |Version:  6.8.2   
 Severity:  normal   | Resolution:  
 Keywords:   | Difficulty:  Unknown 
 Testcase:  typecheck/should_fail/T2307  |   Architecture:  Unknown 
   Os:  Unknown  |  
-+--
Changes (by igloo):

  * status:  closed = reopened
  * resolution:  fixed =
  * milestone:  6.10 branch = 6.10.1

Comment:

 The behaviour when the types in the instances were changed felt a little
 odd to me, so I had a quick look at the code, and I think it's broken;
 e.g. this module:
 {{{
 {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies,
  OverlappingInstances, UndecidableInstances,
 IncoherentInstances,
  FlexibleInstances #-}

 module Foo where

 class C a b c | b - c
 instance C Bool Int Float
 instance C Char Int Double
 }}}
 is accepted by GHC, but violates `b - c`.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2307#comment:3
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


[GHC] #2411: RaiseAsync and STM segfault with stop_at_atomically in some circumstances.

2008-07-01 Thread GHC
#2411: RaiseAsync and STM segfault with stop_at_atomically in some 
circumstances.
+---
Reporter:  sclv |   Owner:  
Type:  bug  |  Status:  new 
Priority:  normal   |   Component:  Compiler
 Version:  6.8.3|Severity:  normal  
Keywords:   |Testcase:  
Architecture:  Unknown  |  Os:  Unknown 
+---
 x86_64 6.9 build from June 15. I can't distill it down to a single simple
 testcase, but the backtrace is very informative:

 ASSERTION FAILED: file RaiseAsync.c, line 1015

 The assertion in question is ASSERT(stmGetEnclosingTRec(tso-trec) ==
 NO_TREC).
 This assertion is only called when we hit an ATOMICALLY_FRAME with
 stop_at_atomically activated.

 We only do that when Schedule.c is running the garbage collector and
 raises an exception to retry an invalid stm transaction. I don't follow
 enough here to offer a real patch, but obviously there is a false
 assumption that the transaction we're trying to retry does not have an
 enclosing trec. Why this may be the case is somewhat beyond me. I'm doing
 various things with unsafeIOToSTM, so I think the answer may be that there
 is some sort of forking going on with threaded IO which means that threads
 may have enclosing trecs.

 {{{
 #0  0x2b134fdb9b45 in raise () from /lib64/libc.so.6
 #1  0x2b134fdbb0e0 in abort () from /lib64/libc.so.6
 #2  0x009b40e0 in rtsFatalInternalErrorFn (s=0xa2c670 ASSERTION
 FAILED: file %s, line %u\n,
 ap=0x41000e50) at RtsMessages.c:164
 #3  0x009b3ca4 in barf (s=0xa2c670 ASSERTION FAILED: file %s,
 line %u\n) at RtsMessages.c:40
 #4  0x009b3cfe in _assertFail (filename=0xa3200c RaiseAsync.c,
 linenum=1015)
 at RtsMessages.c:55
 #5  0x009e4675 in raiseAsync (cap=0xd734a0, tso=0x2b1351bdb000,
 exception=0x0,
 stop_at_atomically=rtsTrue, stop_here=0x0) at RaiseAsync.c:1015
 #6  0x009e365b in throwToSingleThreaded_ (cap=0xd734a0,
 tso=0x2b1351bdb000, exception=0x0,
 ---Type return to continue, or q return to quit---
 stop_at_atomically=rtsTrue, stop_here=0x0) at RaiseAsync.c:73
 #7  0x009b6b51 in scheduleDoGC (cap=0xd734a0, task=0xd8e750,
 force_major=rtsFalse)
 at Schedule.c:2046
 #8  0x009b5a9d in schedule (initialCapability=0xd734a0,
 task=0xd8e750) at Schedule.c:718
 #9  0x009b77db in workerStart (task=0xd8e750) at Schedule.c:2537
 #10 0x2b134fb73020 in start_thread () from /lib64/libpthread.so.0
 #11 0x2b134fe4df8d in clone () from /lib64/libc.so.6
 #12 0x in ?? ()
 }}}

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2411
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #2379: ghc-6.9.20080614: panic! (the 'impossible' happened)

2008-07-01 Thread GHC
#2379: ghc-6.9.20080614: panic! (the 'impossible' happened)
--+-
 Reporter:  megacz|  Owner: 
 Type:  bug   | Status:  new
 Priority:  low   |  Milestone:  6.10.1 
Component:  Compiler  |Version:  6.9
 Severity:  normal| Resolution: 
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  Unknown
   Os:  MacOS X   |  
--+-
Changes (by igloo):

  * priority:  normal = low
  * milestone:  = 6.10.1

Old description:

 [ 7 of 78] Compiling Data.Array.Parallel.Base.Rebox (
 Data/Array/Parallel/Base/Rebox.hs,
 dist/build/Data/Array/Parallel/Base/Rebox.o )
 ghc-6.9.20080614: panic! (the 'impossible' happened)
   (GHC version 6.9.20080614 for i386-apple-darwin):
 initC: srt_lbl

 Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

 ghc: 85934552 bytes, 26 GCs, 2419370/5914624 avg/max bytes residency (3
 samples), 11M in use, 0.00 INIT (0.00 elapsed), 0.17 MUT (1.05 elapsed),
 0.08 GC (0.09 elapsed) :ghc

New description:

 {{{
 [ 7 of 78] Compiling Data.Array.Parallel.Base.Rebox (
 Data/Array/Parallel/Base/Rebox.hs,
 dist/build/Data/Array/Parallel/Base/Rebox.o )
 ghc-6.9.20080614: panic! (the 'impossible' happened)
   (GHC version 6.9.20080614 for i386-apple-darwin):
 initC: srt_lbl

 Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

 ghc: 85934552 bytes, 26 GCs, 2419370/5914624 avg/max bytes residency (3
 samples), 11M in use, 0.00 INIT (0.00 elapsed), 0.17 MUT (1.05 elapsed),
 0.08 GC (0.09 elapsed) :ghc
 }}}

Comment:

 And if it is still broken for you, can you please attach the source code
 you were trying to compile and tell us what the commandline was?

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2379#comment:2
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #2386: Splicing in constructors that are abstract from the point of view of the splice point is unreliable

2008-07-01 Thread GHC
#2386: Splicing in constructors that are abstract from the point of view of the
splice point is unreliable
--+-
 Reporter:  batterseapower|  Owner:
 Type:  bug   | Status:  new   
 Priority:  normal|  Milestone:  6.10.1
Component:  Template Haskell  |Version:  6.8.3 
 Severity:  normal| Resolution:
 Keywords:| Difficulty:  Unknown   
 Testcase:|   Architecture:  x86_64 (amd64)
   Os:  MacOS X   |  
--+-
Changes (by igloo):

  * difficulty:  = Unknown
  * milestone:  = 6.10.1

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2386#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #2349: SIZET_FMT in includes/mkDerivedConstants.c needs to be d under older Solaris version

2008-07-01 Thread GHC
#2349: SIZET_FMT in includes/mkDerivedConstants.c needs to be d under older
Solaris version
--+-
 Reporter:  maeder|  Owner: 
 Type:  bug   | Status:  new
 Priority:  normal|  Milestone:  6.10.1 
Component:  Compiler  |Version:  6.8.2  
 Severity:  normal| Resolution: 
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  sparc  
   Os:  Solaris   |  
--+-
Changes (by igloo):

  * difficulty:  = Unknown
  * milestone:  = 6.10.1

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2349#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #2383: hsc2hs puts -F on call to ghc

2008-07-01 Thread GHC
#2383: hsc2hs puts -F on call to ghc
-+--
 Reporter:  povman   |  Owner: 
 Type:  bug  | Status:  closed 
 Priority:  normal   |  Milestone:  6.10.1 
Component:  hsc2hs   |Version:  6.8.2  
 Severity:  normal   | Resolution:  invalid
 Keywords:   | Difficulty:  Unknown
 Testcase:   |   Architecture:  Unknown
   Os:  MacOS X  |  
-+--
Changes (by ross):

  * status:  new = closed
  * resolution:  = invalid

Comment:

 As Christian has said, this was never in the mainline.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2383#comment:9
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #2352: POSIX.1 unsetenv returns int

2008-07-01 Thread GHC
#2352: POSIX.1 unsetenv returns int
+---
 Reporter:  donn|  Owner:  igloo 
 Type:  bug | Status:  new   
 Priority:  normal  |  Milestone:  6.10.1
Component:  libraries/unix  |Version:  6.8.2 
 Severity:  minor   | Resolution:
 Keywords:  | Difficulty:  Unknown   
 Testcase:  |   Architecture:  x86_64 (amd64)
   Os:  NetBSD  |  
+---
Changes (by igloo):

  * owner:  = igloo
  * difficulty:  = Unknown
  * milestone:  = 6.10.1

Old description:

 While plenty of C libraries declare void unsetenv(), the POSIX.1003.1
 standard is int unsetenv(), with return values 0 or -1.  In the latter
 case, errno is set to EINVAL, for causes including the present of = in
 the value.  Of course this is not of earthshaking importance.

 The following is the autoconf test (just a copy of the same test for
 usleep().)

 --- libraries/unix/configure.ac.dist2008-06-03 10:39:45.0
 -0700
 +++ libraries/unix/configure.ac 2008-06-06 21:43:19.0 -0700
 @@ -75,6 +75,19 @@
;;
  esac

 +###  POSIX.1003.1 unsetenv returns 0 or -1 (EINVAL), but older
 implementations
 +###  in common use return void.
 +AC_CACHE_CHECK([return type of unsetenv], cv_func_unsetenv_return_type,
 +  [AC_EGREP_HEADER(changequote(, )void[
 ]+unsetenvchangequote([, ]),
 +   /usr/include/stdlib.h,
 +   [cv_func_unsetenv_return_type=void],
 +   [cv_func_unsetenv_return_type=int])])
 +case $cv_func_unsetenv_return_type in
 +  void )
 +AC_DEFINE([UNSETENV_RETURNS_VOID], [1], [Define if stdlib.h declares
 unsetenv to return void.])
 +  ;;
 +esac
 +
  dnl ** sometimes RTLD_NEXT is hidden in #ifdefs we really don't wan to
 set
  AC_MSG_CHECKING(for RTLD_NEXT from dlfcn.h)
  AC_EGREP_CPP(yes,

New description:

 While plenty of C libraries declare void unsetenv(), the POSIX.1003.1
 standard is int unsetenv(), with return values 0 or -1.  In the latter
 case, errno is set to EINVAL, for causes including the present of = in
 the value.  Of course this is not of earthshaking importance.

 The following is the autoconf test (just a copy of the same test for
 usleep().)
 {{{
 --- libraries/unix/configure.ac.dist2008-06-03 10:39:45.0
 -0700
 +++ libraries/unix/configure.ac 2008-06-06 21:43:19.0 -0700
 @@ -75,6 +75,19 @@
;;
  esac

 +###  POSIX.1003.1 unsetenv returns 0 or -1 (EINVAL), but older
 implementations
 +###  in common use return void.
 +AC_CACHE_CHECK([return type of unsetenv], cv_func_unsetenv_return_type,
 +  [AC_EGREP_HEADER(changequote(, )void[  ]+unsetenvchangequote([,
 ]),
 +   /usr/include/stdlib.h,
 +   [cv_func_unsetenv_return_type=void],
 +   [cv_func_unsetenv_return_type=int])])
 +case $cv_func_unsetenv_return_type in
 +  void )
 +AC_DEFINE([UNSETENV_RETURNS_VOID], [1], [Define if stdlib.h declares
 unsetenv to return void.])
 +  ;;
 +esac
 +
  dnl ** sometimes RTLD_NEXT is hidden in #ifdefs we really don't wan to
 set
  AC_MSG_CHECKING(for RTLD_NEXT from dlfcn.h)
  AC_EGREP_CPP(yes,
 }}}

Comment:

 Thanks for the patch, we'll take a look

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2352#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #2353: GHC inliner doesn't

2008-07-01 Thread GHC
#2353: GHC inliner doesn't
--+-
 Reporter:  guest |  Owner: 
 Type:  bug   | Status:  new
 Priority:  normal|  Milestone:  6.10 branch
Component:  Compiler  |Version:  6.9
 Severity:  normal| Resolution: 
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  Unknown
   Os:  Unknown   |  
--+-
Changes (by igloo):

  * milestone:  = 6.10 branch

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2353#comment:9
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #2354: NOINLINE pragma ignored

2008-07-01 Thread GHC
#2354: NOINLINE pragma ignored
--+-
 Reporter:  guest |  Owner: 
 Type:  bug   | Status:  new
 Priority:  normal|  Milestone:  6.10.1 
Component:  Compiler  |Version:  6.9
 Severity:  normal| Resolution: 
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  Unknown
   Os:  Unknown   |  
--+-
Changes (by igloo):

  * milestone:  = 6.10.1

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2354#comment:3
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #2356: GHC accepts multiple instances for the same type in different modules

2008-07-01 Thread GHC
#2356: GHC accepts multiple instances for the same type in different modules
--+-
 Reporter:  claus |  Owner: 
 Type:  bug   | Status:  new
 Priority:  high  |  Milestone:  6.10.1 
Component:  Compiler  |Version:  6.8.2  
 Severity:  normal| Resolution: 
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  Unknown
   Os:  Unknown   |  
--+-
Changes (by igloo):

  * priority:  normal = high
  * difficulty:  = Unknown
  * milestone:  = 6.10.1

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2356#comment:2
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #2402: ghc fails sans error message.

2008-07-01 Thread GHC
#2402: ghc fails sans error message.
--+-
 Reporter:  lpsmith   |  Owner: 
 Type:  bug   | Status:  new
 Priority:  normal|  Milestone:  6.10.1 
Component:  Compiler  |Version:  6.8.3  
 Severity:  normal| Resolution: 
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  powerpc
   Os:  MacOS X   |  
--+-
Changes (by igloo):

  * milestone:  = 6.10.1

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2402#comment:4
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #2401: unsafeIOToSTM hangs with 64 bit multicore.

2008-07-01 Thread GHC
#2401: unsafeIOToSTM hangs with 64 bit multicore.
+---
 Reporter:  sclv|  Owner: 
 Type:  bug | Status:  new
 Priority:  normal  |  Milestone:  6.10.1 
Component:  Runtime System  |Version:  6.8.3  
 Severity:  major   | Resolution: 
 Keywords:  | Difficulty:  Unknown
 Testcase:  |   Architecture:  Unknown
   Os:  Unknown |  
+---
Changes (by igloo):

  * difficulty:  = Unknown
  * milestone:  = 6.10.1

Comment:

 Thanks for the report; I don't /think/ that the `unsafeIOToSTM` should be
 to blame, although I'm not too familiar with STM.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2401#comment:3
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #2398: segfault in cmpLocks on 64 bit multicore

2008-07-01 Thread GHC
#2398: segfault in cmpLocks on 64 bit multicore
+---
 Reporter:  sclv|  Owner: 
 Type:  bug | Status:  new
 Priority:  low |  Milestone:  6.10.1 
Component:  Runtime System  |Version:  6.8.3  
 Severity:  major   | Resolution: 
 Keywords:  | Difficulty:  Unknown
 Testcase:  |   Architecture:  Unknown
   Os:  Linux   |  
+---
Changes (by igloo):

  * priority:  normal = low
  * difficulty:  = Unknown
  * milestone:  = 6.10.1

Comment:

 I can't reproduce this using the first 351k of my exim `spec.txt` as the
 file contents, compiling with GHC 6.8.3:
 {{{
 ghc -fforce-recomp --make q -O -threaded
 }}}
 and running with just
 {{{
 ./q
 }}}
 or
 {{{
 ./q +RTS -N3
 }}}
 on an amd64/Linux machine. I do get a load of
 {{{
 q: foo/984: openFile: resource exhausted (Too many open files)
 }}}
 but that is to be expected. It would be useful if you could attach a text
 file that triggers the problem for you, and give details of how you are
 compiling and running the program.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2398#comment:4
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #2358: Template Haskell's TupleT considers unary tuples as a valid types.

2008-07-01 Thread GHC
#2358: Template Haskell's TupleT considers unary tuples as a valid types.
--+-
 Reporter:  fons  |  Owner:  igloo 
 Type:  merge | Status:  new   
 Priority:  normal|  Milestone:  6.8 branch
Component:  Template Haskell  |Version:  6.8.2 
 Severity:  normal| Resolution:
 Keywords:| Difficulty:  Unknown   
 Testcase:  TH_1tuple |   Architecture:  Unknown   
   Os:  Unknown   |  
--+-
Changes (by igloo):

  * milestone:  = 6.8 branch

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2358#comment:2
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #2378: panic: lookupVers1, when standalone deriving Typeable and Data

2008-07-01 Thread GHC
#2378: panic: lookupVers1, when standalone deriving Typeable and Data
---+
 Reporter:  guest  |  Owner:  igloo 
 Type:  merge  | Status:  new   
 Priority:  normal |  Milestone:  6.8 branch
Component:  Compiler   |Version:  6.8.3 
 Severity:  normal | Resolution:
 Keywords: | Difficulty:  Unknown   
 Testcase:  deriving/should_compile/T2378  |   Architecture:  x86   
   Os:  MacOS X|  
---+
Changes (by igloo):

  * milestone:  = 6.8 branch

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2378#comment:6
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #2398: segfault in cmpLocks on 64 bit multicore

2008-07-01 Thread GHC
#2398: segfault in cmpLocks on 64 bit multicore
+---
 Reporter:  sclv|  Owner: 
 Type:  bug | Status:  new
 Priority:  low |  Milestone:  6.10.1 
Component:  Runtime System  |Version:  6.8.3  
 Severity:  major   | Resolution: 
 Keywords:  | Difficulty:  Unknown
 Testcase:  |   Architecture:  Unknown
   Os:  Linux   |  
+---
Comment (by sclv):

 {{{
  ghc --make -threaded -O2 -debug testfi.hs
  gdb --args ./testfi +RTS -N4
 (gdb) run

 [Lots of text removed]

 Program received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 0x43806950 (LWP 1248)]
 0x0043990c in cmpLocks (w1=531, w2=1132470304) at
 posix/FileLock.c:35
 35  return (l1-device == l2-device  l1-inode == l2-inode);

 (gdb) bt

 #0  0x0043990c in cmpLocks (w1=531, w2=1132470304) at
 posix/FileLock.c:35
 #1  0x00458166 in lookupHashTable (table=0x6ae110, key=1132470304)
 at Hash.c:197
 #2  0x00439a1d in lockFile (fd=533, dev=2055, ino=10584501,
 for_writing=0)at posix/FileLock.c:73
 #3  0x0040597a in s7AW_info ()
 #4  0x00060012 in ?? ()
 #5  0x00405e28 in scJ1_info ()
 #6  0x00405e10 in scJ1_info ()
 #7  0x00444a00 in ?? ()
 #8  0x2ab15c50 in ?? ()
 #9  0x00405e40 in scJ1_info ()
 #10 0x2ab15c50 in ?? ()
 #11 0x in ?? ()
 }}}

 Again this is on an Intel Core 2 Quad. I'm now running it on a 6.9
 snapshot from June 15, by the way, and getting the same result. Note that
 it seems to happen 75% of the time at least at -N4. At -N3 I'm getting it
 25% of the time or so. I'll attach the file I'm using as well, although I
 doubt that should have much impact on the results.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2398#comment:5
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #2398: segfault in cmpLocks on 64 bit multicore

2008-07-01 Thread GHC
#2398: segfault in cmpLocks on 64 bit multicore
+---
 Reporter:  sclv|  Owner: 
 Type:  bug | Status:  new
 Priority:  low |  Milestone:  6.10.1 
Component:  Runtime System  |Version:  6.8.3  
 Severity:  major   | Resolution: 
 Keywords:  | Difficulty:  Unknown
 Testcase:  |   Architecture:  Unknown
   Os:  Linux   |  
+---
Comment (by sclv):

 Looking through the code, it seems to me that the HashTable used by
 FileLock.c isn't concurrent/threadsafe, and neither FileLock.c nor the
 foreign call to it from GHC.Handle serialize access.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2398#comment:6
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs