[GHC] #2332: Can't allocate 4 gigs of RAM

[GHC]

#2332: Can't allocate 4 gigs of RAM
--+-
Reporter:  mightybyte |   Owner:  
Type:  bug|  Status:  new 
Priority:  normal |   Component:  Compiler
 Version:  6.8.2  |Severity:  normal  
Keywords:  memory allocation  |Testcase:  
Architecture:  x86_64 (amd64) |  Os:  Linux   
--+-
 The program at http://hpaste.org/8058 produces a segmentation fault on my
 machine.  I have 8 gigs of RAM, running 64-bit Ubuntu with 64-bit ghc.
 See http://hpaste.org/8057 for another version of the same problem when
 using larger sizes.

-- 
Ticket URL: 
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] #2331: Bang pattern error message should suggest -XBangPatterns rather than -fbang-patterns

[GHC]

#2331: Bang pattern error message should suggest -XBangPatterns rather than
-fbang-patterns
+---
Reporter:  ajd  |   Owner:  
Type:  bug  |  Status:  new 
Priority:  normal   |   Component:  Compiler
 Version:  6.8.2|Severity:  normal  
Keywords:   |Testcase:  
Architecture:  Unknown  |  Os:  Unknown 
+---
 {{{
 Prelude> let f (!x) = True
 :1:6: Illegal bang-pattern (use -fbang-patterns)
 }}}

 Since GHC is encouraging the use of -X options, shouldn't this suggest
 -XBangPatterns?

-- 
Ticket URL: 
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: bug with type families

[Peter Gavin]

Stefan Holdermans wrote:

Peter,


I've run into a bug that looks to be the same as the one described here:

http://hackage.haskell.org/trac/ghc/ticket/1897


It does not seem like a bug, although the type-error message may be a 
bit confusing as is the fact that GHC happily infers a type for the 
signature-less function: these are I guess the real issues here. But, 
apart from that, the contents of a previous discussion seems to apply here:


  http://www.haskell.org/pipermail/haskell-cafe/2008-April/041385.html

Short version: the type of isValid involves |Depend s| and not |s|. 
Since |Depend s| does not uniquely determine |s|, it is not possible to 
resolve which dictionary for Bug to supply for a particular call to 
isValid.


Or---am I overlooking something?



No, that makes perfect sense to me now. Thanks.

I put up a note on #1897 pointing to that thread, but left it open 
because the error message needs to be fixed :)



Pete
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1897: Type families: type signature rejected

[GHC]

#1897: Type families: type signature rejected
-+--
 Reporter:  guest|  Owner:  chak   
 Type:  bug  | Status:  new
 Priority:  normal   |  Milestone:  6.10 branch
Component:  Compiler (Type checker)  |Version:  6.9
 Severity:  normal   | Resolution: 
 Keywords:   | Difficulty:  Unknown
 Testcase:   |   Architecture:  x86
   Os:  Linux|  
-+--
Comment (by pgavin):

 just a note: it seems that the following thread may apply, in case someone
 else runs into this problem:

 http://www.haskell.org/pipermail/haskell-cafe/2008-April/041397.html

-- 
Ticket URL: 
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] #2002: problems with very large (list) literals

[GHC]

#2002: problems with very large (list) literals
--+-
 Reporter:  Isaac Dupree  |  Owner:  simonmar   
 Type:  compile-time performance bug  | Status:  new
 Priority:  high  |  Milestone:  6.10 branch
Component:  Compiler  |Version:  6.8.2  
 Severity:  normal| Resolution: 
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  x86
   Os:  Linux |  
--+-
Comment (by Isaac Dupree):

 -O0 -fasm succeeded within 3 minutes and 400 MB RAM or so.

 {{{
 ./compiler/stage1/ghc-inplace -no-user-package-conf -H128m -O0 -fasm
 -istage2/utils  -istage2/basicTypes  -istage2/types  -istage2/hsSyn
 -istage2/prelude  -istage2/rename  -istage2/typecheck  -istage2/deSugar
 -istage2/coreSyn  -istage2/vectorise  -istage2/specialise
 -istage2/simplCore  -istage2/stranal  -istage2/stgSyn  -istage2/simplStg
 -istage2/codeGen  -istage2/main  -istage2/profiling  -istage2/parser
 -istage2/cprAnalysis  -istage2/iface  -istage2/cmm  -istage2/nativeGen
 -istage2/ghci -Wall -fno-warn-name-shadowing -fno-warn-orphans -Istage2
 -package hpc -package bytestring -DGHCI -package template-haskell
 -DGHCI_TABLES_NEXT_TO_CODE -I../libffi/build/include -cpp -fglasgow-exts
 -fno-generics -Rghc-timing -I. -Iparser -Iutil -package unix -package
 Cabal -ignore-package lang -recomp -Rghc-timing -O0 -fasm -DDEBUG -H16M
 '-#include "cutils.h"' -package-name  ghc-6.9.20080602   -fgenerics
 -funbox-strict-fields  -c parser/Lexer.hs -o stage2/parser/Lexer.o  -ohi
 stage2/parser/Lexer.hi
 Binary: expanding to size: 6144
 Binary: expanding to size: 6144
 Binary: expanding to size: 6144
 Binary: expanding to size: 6144
 <>
 }}}

 new summary:

 -O0 -fasm completely works, though it's slower than ideal.

 -O0 -fvia-C dies because GCC isn't prepared for how much we're throwing at
 it.  Seems hard for us to fix: lucky we're working on the NCG (though
 possibly ghc -O would simplify the generated C code enough for GCC to
 survive, but that'd be IMHO unlikely in this case).  (though I wonder if
 the GCC people know, or should know, that their compiler behaves poorly in
 these artificial-but-real cases)

 -O takes way too long (I only thoroughly tested -O with -fasm, so the slow
 optimizations could be Core, Cmm, anything; and maybe it succeeds in an
 hour's time, I don't know, would you like me to test on my computer for up
 to a whole day?).  I'm not entirely surprised, but it's still a somewhat
 serious bug from my point of view.


 -Isaac

-- 
Ticket URL: 
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] #2002: problems with very large (list) literals

[GHC]

#2002: problems with very large (list) literals
--+-
 Reporter:  Isaac Dupree  |  Owner:  simonmar   
 Type:  compile-time performance bug  | Status:  new
 Priority:  high  |  Milestone:  6.10 branch
Component:  Compiler  |Version:  6.8.2  
 Severity:  normal| Resolution: 
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  x86
   Os:  Linux |  
--+-
Comment (by Isaac Dupree):

 update: with my 2 GB RAM and 3 GB swap space, gcc took a long time
 swapping, but got in a good 2 minutes of CPU time according to `top` (cc1
 achieving about 80% of my RAM used at any one time, and between 0 and 50
 percent of my 2GHz CPU) before dying due to lack of virtual memory.

 Therefore, it seems that while there is a moderate performance issue with
 GHC through STG (2 minutes for a single file?), the assembly is the really
 difficult part: GCC needs an obscene amount of memory, and GHC's -fasm
 either needs an obscene or infinite amount of time.  But let me check back
 again... that might have been the optimizations and my cutting corners...

 {{{
 Makefile:1004: LIBRARY is libHSghc.a
 ../compiler/stage1/ghc-inplace -no-user-package-conf -H128m -O0 -fvia-C
 -istage2/utils  -istage2/basicTypes  -istage2/types  -istage2/hsSyn
 -istage2/prelude  -istage2/rename  -istage2/typecheck  -istage2/deSugar
 -istage2/coreSyn  -istage2/vectorise  -istage2/specialise
 -istage2/simplCore  -istage2/stranal  -istage2/stgSyn  -istage2/simplStg
 -istage2/codeGen  -istage2/main  -istage2/profiling  -istage2/parser
 -istage2/cprAnalysis  -istage2/iface  -istage2/cmm  -istage2/nativeGen
 -istage2/ghci -Wall -fno-warn-name-shadowing -fno-warn-orphans -Istage2
 -package hpc -package bytestring -DGHCI -package template-haskell
 -DGHCI_TABLES_NEXT_TO_CODE -I../libffi/build/include -cpp -fglasgow-exts
 -fno-generics -Rghc-timing -I. -Iparser -Iutil -package unix -package
 Cabal -ignore-package lang -recomp -Rghc-timing -O0 -fvia-C -DDEBUG -H16M
 '-#include "cutils.h"' -package-name  ghc-6.9.20080602   -fgenerics
 -funbox-strict-fields  -c parser/Lexer.hs -o stage2/parser/Lexer.o  -ohi
 stage2/parser/Lexer.hi
 Binary: expanding to size: 6144
 Binary: expanding to size: 6144
 Binary: expanding to size: 6144
 Binary: expanding to size: 6144
 virtual memory exhausted: Cannot allocate memory
 <>
 make: *** [stage2/parser/Lexer.o] Error 1
 }}}

-- 
Ticket URL: 
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] #2002: problems with very large (list) literals

[GHC]

#2002: problems with very large (list) literals
--+-
 Reporter:  Isaac Dupree  |  Owner:  simonmar   
 Type:  compile-time performance bug  | Status:  new
 Priority:  high  |  Milestone:  6.10 branch
Component:  Compiler  |Version:  6.8.2  
 Severity:  normal| Resolution: 
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  x86
   Os:  Linux |  
--+-
Comment (by Isaac Dupree):

 There is still an issue here, with HEAD self-compiling its
 parser/Lexer.{hs|x} generated by `alex` without `-g`.  I have it here with
 15 minutes of 2GHz CPU time and about 250MB memory used constantly
 according to `top`, and no evidence of finishing.

 {{{
 ../compiler/stage1/ghc-inplace -no-user-package-conf -H128m -O0 -fasm
 -istage2/utils  -istage2/basicTypes  -istage2/types  -istage2/hsSyn
 -istage2/prelude  -istage2/rename  -istage2/typecheck  -istage2/deSugar
 -istage2/coreSyn  -istage2/vectorise  -istage2/specialise
 -istage2/simplCore  -istage2/stranal  -istage2/stgSyn  -istage2/simplStg
 -istage2/codeGen  -istage2/main  -istage2/profiling  -istage2/parser
 -istage2/cprAnalysis  -istage2/iface  -istage2/cmm  -istage2/nativeGen
 -istage2/ghci -Wall -fno-warn-name-shadowing -fno-warn-orphans -Istage2
 -package hpc -package bytestring -DGHCI -package template-haskell
 -DGHCI_TABLES_NEXT_TO_CODE -I../libffi/build/include -cpp -fglasgow-exts
 -fno-generics -Rghc-timing -I. -Iparser -Iutil -package unix -package
 Cabal -ignore-package lang -recomp -Rghc-timing -O0 -fasm -DDEBUG -H16M
 '-#include "cutils.h"' -package-name  ghc-6.9.20080602   -fgenerics
 -funbox-strict-fields  -c parser/Lexer.hs -o stage2/parser/Lexer.o  -ohi
 stage2/parser/Lexer.hi
 }}}
 Same with -O as -O0 and -fvia-C instead of -fasm (gcc & friends never
 start, presumably because GHC hasn't gotten that far)... Oh wait, -fvia-C
 after 2 minutes GHC CPU, it goes into cc1 (gcc) which is taking all my RAM
 memory. Hang on a moment, I'll report back when it's done or crashed, I
 need to free up memory :-)

 Hmm... it appears some of the settings in my mk/build.mk (-H128M) are
 being overridden by compiler/Makefile (-H16M).  Odd.

 It's a bit tricky to reproduce, because we obviously we don't expect 6.8
 and previous to succeed.  I first got a working stage1, then proceeded to
 modify mk/config.mk{,.in} to delete the `-g` from the `GHC_ALEX_OPTS`
 line, then removed the file compiler/parser/Lexer.hs (to make sure it
 would be regenerated with the new settings), then `cd compiler` and `make
 stage=2`.  Obviously simpler test cases could exist, but it's not simple
 to see how to simplify this instance of GHC getting overwhelmed without
 wrecking it

-- 
Ticket URL: 
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] #1970: ghci -hide-all-packages gives bad error message

[GHC]

#1970: ghci -hide-all-packages gives bad error message
-+--
 Reporter:  dfranke  |  Owner:  igloo 
 Type:  merge| Status:  closed
 Priority:  normal   |  Milestone:  6.8 branch
Component:  GHCi |Version:  6.8.1 
 Severity:  trivial  | Resolution:  fixed 
 Keywords:   | Difficulty:  Unknown   
 Testcase:   |   Architecture:  x86_64 (amd64)
   Os:  Linux|  
-+--
Changes (by igloo):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Merged

-- 
Ticket URL: 
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] #2231: GHC RTS Segfault

[GHC]

#2231: GHC RTS Segfault
+---
 Reporter:  guest   |  Owner:  simonpj   
 Type:  bug | Status:  new   
 Priority:  high|  Milestone:  6.10 branch   
Component:  Runtime System  |Version:  6.8.2 
 Severity:  normal  | Resolution:
 Keywords:  | Difficulty:  Unknown   
 Testcase:  |   Architecture:  x86_64 (amd64)
   Os:  Linux   |  
+---
Changes (by igloo):

  * type:  merge => bug

-- 
Ticket URL: 
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] #2231: GHC RTS Segfault

[GHC]

#2231: GHC RTS Segfault
+---
 Reporter:  guest   |  Owner:  simonpj   
 Type:  merge   | Status:  new   
 Priority:  high|  Milestone:  6.10 branch   
Component:  Runtime System  |Version:  6.8.2 
 Severity:  normal  | Resolution:
 Keywords:  | Difficulty:  Unknown   
 Testcase:  |   Architecture:  x86_64 (amd64)
   Os:  Linux   |  
+---
Changes (by igloo):

  * owner:  igloo => simonpj
  * milestone:  6.8.3 => 6.10 branch

Comment:

 Merged

-- 
Ticket URL: 
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: bug with type families

[Stefan Holdermans]

Peter,

I've run into a bug that looks to be the same as the one described  
here:


http://hackage.haskell.org/trac/ghc/ticket/1897


It does not seem like a bug, although the type-error message may be a  
bit confusing as is the fact that GHC happily infers a type for the  
signature-less function: these are I guess the real issues here. But,  
apart from that, the contents of a previous discussion seems to apply  
here:


  http://www.haskell.org/pipermail/haskell-cafe/2008-April/041385.html

Short version: the type of isValid involves |Depend s| and not |s|.  
Since |Depend s| does not uniquely determine |s|, it is not possible  
to resolve which dictionary for Bug to supply for a particular call to  
isValid.


Or---am I overlooking something?

Cheers,

  Stefan
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

bug with type families

[Peter Gavin]

Hello,

I've run into a bug that looks to be the same as the one described here:

http://hackage.haskell.org/trac/ghc/ticket/1897

That bug was reported 7 months ago, and I didn't want to modify the bug 
 just to add a "me too" entry to it.  Is this a major bug that I 
shouldn't expect to be fixed for a while?


BTW, type families work great otherwise, and I appreciate all the work 
put in to GHC in general :)


Thanks a lot,
Peter Gavin
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #2209: MagicHash extraction is wrong on x86_64 with -fasm -O2

[GHC]

#2209: MagicHash extraction is wrong on x86_64 with -fasm -O2
--+-
 Reporter:  quark |  Owner:  igloo 
 Type:  merge | Status:  closed
 Priority:  normal|  Milestone:  6.8.3 
Component:  Compiler  |Version:  6.8.2 
 Severity:  major | Resolution:  fixed 
 Keywords:| Difficulty:  Unknown   
 Testcase:|   Architecture:  x86_64 (amd64)
   Os:  Linux |  
--+-
Changes (by igloo):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Merged

-- 
Ticket URL: 
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] #2306: The (^) operator sometimes uses one (*) more than needed.

[GHC]

#2306: The (^) operator sometimes uses one (*) more than needed.
-+--
 Reporter:  guest|  Owner:  igloo  
 Type:  bug  | Status:  closed 
 Priority:  normal   |  Milestone:  6.8.3  
Component:  Prelude  |Version:  6.8.2  
 Severity:  minor| Resolution:  fixed  
 Keywords:   | Difficulty:  Unknown
 Testcase:   |   Architecture:  Unknown
   Os:  Unknown  |  
-+--
Changes (by igloo):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 It's now
 {{{
 (^) :: (Num a, Integral b) => a -> b -> a
 x0 ^ y0 | y0 < 0= error "Negative exponent"
 | y0 == 0   = 1
 | otherwise = f x0 y0
 where -- f : x0 ^ y0 = x ^ y
   f x y | even y= f (x * x) (y `quot` 2)
 | y == 1= x
 | otherwise = g (x * x) ((y - 1) `quot` 2) x
   -- g : x0 ^ y0 = (x ^ y) * z
   g x y z | even y = g (x * x) (y `quot` 2) z
   | y == 1 = x * z
   | otherwise = g (x * x) ((y - 1) `quot` 2) (x * z)
 }}}
 in the HEAD and 6.8 branch.

-- 
Ticket URL: 
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] #2329: Control.Parallel.Strategies: definitions of rnf for most collections are poor

[GHC]

#2329: Control.Parallel.Strategies: definitions of rnf for most collections are
poor
-+--
Reporter:  bos   |Owner: 
Type:  run-time performance bug  |   Status:  new
Priority:  normal|Milestone: 
   Component:  libraries/base|  Version:  6.8.2  
Severity:  normal|   Resolution: 
Keywords:| Testcase: 
Architecture:  Unknown   |   Os:  Unknown
-+--
Comment (by ross):

 All but IntSet are instances of Foldable, and so have
 Data.Foldable.foldl'.

-- 
Ticket URL: 
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] #2330: ghc-pkg should not report duplicate depends

[GHC]

#2330: ghc-pkg should not report duplicate depends
+---
Reporter:  duncan   |   Owner:  
Type:  bug  |  Status:  new 
Priority:  normal   |   Component:  Compiler
 Version:  6.8.2|Severity:  normal  
Keywords:   |Testcase:  
Architecture:  Unknown  |  Os:  Unknown 
+---
 {{{
 $ ghc-pkg field regex-base-0.72.0.1 depends
 depends: base-3.0.1.0 array-0.1.0.0 base-3.0.1.0 bytestring-0.9.0.1
 }}}

 Note the `base-3.0.1.0 base-3.0.1.0`. This is clearly silly. It causes
 problems for Cabal. Although we can easily work around this using nub it'd
 be better if duplicate depends were never reported or better yet rejected
 or eliminated at package registration time.

 (I'm not sure how it ended up this way, I don't think Cabal makes package
 registration files with duplicate depends)

-- 
Ticket URL: 
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] #2329: Control.Parallel.Strategies: definitions of rnf for most collections are poor

[GHC]

#2329: Control.Parallel.Strategies: definitions of rnf for most collections are
poor
-+--
Reporter:  bos   |   Owner:
Type:  run-time performance bug  |  Status:  new   
Priority:  normal|   Component:  libraries/base
 Version:  6.8.2 |Severity:  normal
Keywords:|Testcase:
Architecture:  Unknown   |  Os:  Unknown   
-+--
 These all perform a lot of consing, which seems rather undesirable.  It
 would be very nice indeed if they could be rebaked in terms of strict left
 folds.  Unfortunately, all of the collections in question seem only to
 expose non-strict left folds publicly.

 {{{
 instance (NFData k, NFData a) => NFData (Data.Map.Map k a) where
 rnf = rnf . Data.Map.toList

 instance NFData a => NFData (Data.Set.Set a) where
 rnf = rnf . Data.Set.toList

 instance NFData a => NFData (Data.Tree.Tree a) where
 rnf (Data.Tree.Node r f) = rnf r `seq` rnf f

 instance NFData a => NFData (Data.IntMap.IntMap a) where
 rnf = rnf . Data.IntMap.toList

 instance NFData Data.IntSet.IntSet where
 rnf = rnf . Data.IntSet.toList
 }}}

-- 
Ticket URL: 
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] #2231: GHC RTS Segfault

[GHC]

#2231: GHC RTS Segfault
+---
 Reporter:  guest   |  Owner:  igloo 
 Type:  merge   | Status:  new   
 Priority:  high|  Milestone:  6.8.3 
Component:  Runtime System  |Version:  6.8.2 
 Severity:  normal  | Resolution:
 Keywords:  | Difficulty:  Unknown   
 Testcase:  |   Architecture:  x86_64 (amd64)
   Os:  Linux   |  
+---
Changes (by simonmar):

  * owner:  simonmar => igloo
  * type:  bug => merge

Comment:

 I've fixed the crash:

 {{{
 Mon Jun  2 07:37:26 PDT 2008  Simon Marlow <[EMAIL PROTECTED]>
   * FIX #2231: add missing stack check when applying a PAP
 }}}

 The assertion failure in the type checker is still there and appears to be
 unrelated. We have no evidence that it is actually causing a problem,
 `-dcore-lint` still passes,

 Ian: please merge, then re-assign to Simon and move the ticket to the 6.10
 milestone.

-- 
Ticket URL: 
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] #1818: Code size increase vs. 6.6.1

[GHC]

#1818: Code size increase vs. 6.6.1
--+-
 Reporter:  simonmar  |  Owner:
 Type:  run-time performance bug  | Status:  closed
 Priority:  high  |  Milestone:  6.8.3 
Component:  Compiler  |Version:  6.8.1 
 Severity:  normal| Resolution:  worksforme
 Keywords:| Difficulty:  Unknown   
 Testcase:|   Architecture:  Unknown   
   Os:  Unknown   |  
--+-
Changes (by simonmar):

  * status:  new => closed
  * resolution:  => worksforme

Comment:

 I measured a 5% code size difference between 6.8.2 and 6.8.3, but on
 recompiling a fresh 6.8.2 tree with exactly the same build options as were
 used for 6.8.3, the difference disappeared.  I suspect something caused by
 a difference in options, so probably not a 6.6.1->6.8.1 regression, and
 hence I'll close the bug.

-- 
Ticket URL: 
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] #2328: Compiling DoCon with 6.8.3 has 3x slow-down compared with 6.8.2

[GHC]

#2328: Compiling DoCon with 6.8.3 has 3x slow-down compared with 6.8.2
-+--
Reporter:  simonpj   |   Owner: 
Type:  compile-time performance bug  |  Status:  new
Priority:  normal|   Milestone: 
   Component:  Compiler  | Version:  6.8.2  
Severity:  normal|Keywords: 
  Difficulty:  Unknown   |Testcase: 
Architecture:  Unknown   |  Os:  Unknown
-+--
 Serge reports that "there remains the question:
 why GHC 6.8.3 release candidate builds !DoCon-2.11 considerably slower
 than ghc-6.8.2
 (3 times, as I recall)
 and needs larger -M memory to build this !DoCon".

 A 3x slow-down wrt 6.8.2 is quite unexpected.

 Simon

-- 
Ticket URL: 
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] #2013: ghci crash on startup: R_X86_64_32S relocation out of range.

[GHC]

#2013: ghci crash on startup: R_X86_64_32S relocation out of range.
-+--
 Reporter:  mboes|  Owner:  simonmar  
 Type:  bug  | Status:  closed
 Priority:  high |  Milestone:  6.8.3 
Component:  GHCi |Version:  6.9   
 Severity:  normal   | Resolution:  fixed 
 Keywords:   | Difficulty:  Unknown   
 Testcase:   |   Architecture:  x86_64 (amd64)
   Os:  FreeBSD  |  
-+--
Changes (by simonmar):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 I pushed (a slight variant of) 2013.patch.

-- 
Ticket URL: 
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] #2231: GHC RTS Segfault

[GHC]

#2231: GHC RTS Segfault
+---
 Reporter:  guest   |  Owner:  simonmar  
 Type:  bug | Status:  new   
 Priority:  high|  Milestone:  6.8.3 
Component:  Runtime System  |Version:  6.8.2 
 Severity:  normal  | Resolution:
 Keywords:  | Difficulty:  Unknown   
 Testcase:  |   Architecture:  x86_64 (amd64)
   Os:  Linux   |  
+---
Comment (by simonmar):

 Using the latest 6.8.3 code with DEBUG on, I get an assertion failure:

 {{{
 /64playpen/simonmar/2231 > ~/nightly-stable/compiler/stage2/ghc-inplace
 --make Control/Concurrent/Session/Queens.hs
 [ 1 of 12] Compiling Control.Concurrent.Session.SMonad (
 Control/Concurrent/Session/SMonad.hs, Control/Concurrent/Session/SMonad.o
 )
 [ 2 of 12] Compiling Control.Concurrent.Session.Bool (
 Control/Concurrent/Session/Bool.hs, Control/Concurrent/Session/Bool.o )
 [ 3 of 12] Compiling Control.Concurrent.Session.Number (
 Control/Concurrent/Session/Number.hs, Control/Concurrent/Session/Number.o
 )
 [ 4 of 12] Compiling Control.Concurrent.Session.List (
 Control/Concurrent/Session/List.hs, Control/Concurrent/Session/List.o )
 [ 5 of 12] Compiling Control.Concurrent.Session.SessionType (
 Control/Concurrent/Session/SessionType.hs,
 Control/Concurrent/Session/SessionType.o )
 [ 6 of 12] Compiling Control.Concurrent.Session.Runtime (
 Control/Concurrent/Session/Runtime.hs,
 Control/Concurrent/Session/Runtime.o )
 ghc-6.8.2.20080601: panic! (the 'impossible' happened)
   (GHC version 6.8.2.20080601 for x86_64-unknown-linux):
 ASSERT failed! file typecheck/TcMType.lhs line 442 t_a7Fa{tv}
 [tau]

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

 Since this might be related to the resulting crash, I'll confer with Simon
 PJ before debugging further.

-- 
Ticket URL: 
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] #2231: GHC RTS Segfault

[GHC]

#2231: GHC RTS Segfault
+---
 Reporter:  guest   |  Owner:  simonmar  
 Type:  bug | Status:  new   
 Priority:  high|  Milestone:  6.8.3 
Component:  Runtime System  |Version:  6.8.2 
 Severity:  normal  | Resolution:
 Keywords:  | Difficulty:  Unknown   
 Testcase:  |   Architecture:  x86_64 (amd64)
   Os:  Linux   |  
+---
Changes (by simonmar):

  * owner:  igloo => simonmar

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