Re: [GHC] #5201: unregisterised build broken on arm-linux platform

2011-05-16 Thread GHC
#5201: unregisterised build broken on arm-linux platform
+---
Reporter:  kgardas  |   Owner:  igloo  
Type:  bug  |  Status:  new
Priority:  normal   |   Component:  Build System   
 Version:  7.0.3|Keywords: 
Testcase:   |   Blockedby: 
  Os:  Linux|Blocking: 
Architecture:  arm  | Failure:  Building GHC failed
+---
Changes (by PHO):

 * cc: pho@… (added)


-- 
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] #1070: Add hPutNonBlocking to Data.ByteString

2011-05-16 Thread GHC
#1070: Add hPutNonBlocking to Data.ByteString
+---
  Reporter:  guest  |  Owner:  duncan  
  Type:  feature request| Status:  closed  
  Priority:  high   |  Milestone:  7.2.1   
 Component:  libraries (other)  |Version:  6.6 
Resolution:  fixed  |   Keywords:  
  Testcase: |  Blockedby:  
Difficulty:  Unknown| Os:  Unknown/Multiple
  Blocking: |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown   |  
+---
Changes (by duncan):

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


Comment:

 I have decided to add the function with this type:
 {{{
 hPutNonBlocking :: Handle -> ByteString -> IO ByteString
 }}}
 That is, it returns the unwritten tail, if any. This generalised better to
 the lazy bytestring case. In the lazy bytestring case, using the number of
 bytes written would mean that any correct program would necessarily have a
 space leak.

 This change is now in the upstream darcs repo and will be in
 bytestring-0.9.2.0 which will be released soonish.

-- 
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] #5201: unregisterised build broken on arm-linux platform

2011-05-16 Thread GHC
#5201: unregisterised build broken on arm-linux platform
+---
Reporter:  kgardas  |   Owner:  igloo  
Type:  bug  |  Status:  new
Priority:  normal   |   Component:  Build System   
 Version:  7.0.3|Keywords: 
Testcase:   |   Blockedby: 
  Os:  Linux|Blocking: 
Architecture:  arm  | Failure:  Building GHC failed
+---
 Hello,

 following git patch probably breaks unregisterised build on any platform
 for which NCG is not available (ARM, MIPS, IA64 etc.)

 {{{
 commit 066b369de2c6f7da03c88206288dca29ab061b31
 Author: Ian Lynagh 
 Date:   Sun May 1 15:38:18 2011 +0100

 Remove the OMIT_NATIVE_CODEGEN ifdef

 We now test
 cGhcWithNativeCodeGen == "YES"
 instead.

 }}}

 the issue I see on ARM/Linux platform is this:

 {{{

 compiler/nativeGen/AsmCodeGen.lhs:39:0:
  error: #error "AsmCodeGen: unknown architecture"
 make[1]: *** [compiler/stage1/build/.depend-v.haskell] Error 1
 make: *** [all] Error 2

 }}}

-- 
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] #4065: Inconsistent loop performance

2011-05-16 Thread GHC
#4065: Inconsistent loop performance
-+--
Reporter:  rl|Owner: 
Type:  bug   |   Status:  new
Priority:  normal|Milestone:  7.2.1  
   Component:  Compiler  |  Version:  6.13   
Keywords:| Testcase: 
   Blockedby:|   Difficulty: 
  Os:  Unknown/Multiple  | Blocking: 
Architecture:  Unknown/Multiple  |  Failure:  Runtime performance bug
-+--

Comment(by daniel.is.fischer):

 I just ran the benchmark with 7.0.3, I get the reverse outcome with that,
 foo takes about 48ms and bar about 42ms. Via C (-O2 -fvia-C -optc-O3),
 both take 40-41ms (bar is typically a bit faster).
 So, unless it's platform-dependent, the new code generator seems to have
 turned things around.

 The core looks fine for both, basically
 {{{
 case n of
   0# -> ...
   _  -> ...

 case n <=# 0# of
   True  -> ...
   False -> ...
 }}}
 for the workers. I don't understand cmm, so I'm guessing, the relevant
 parts seem to be
 {{{
 cnO:
 _sn9::I32 = I32[Sp + 0];
 if (_sn9::I32 != 0) goto cnS;
 R1 = I32[Sp + 4];
 Sp = Sp + 8;
 jump (I32[Sp + 0]) ();
 cnS:
 _snI::I32 = I32[Sp + 4] + 1;
 _snJ::I32 = _sn9::I32 - 1;
 I32[Sp + 4] = _snI::I32;
 I32[Sp + 0] = _snJ::I32;
 jump FooBar_zdwbar_info ();
 }}}
 for bar and
 {{{
 coF:
 _coI::I32 = %MO_S_Le_W32(I32[Sp + 0], 0);
 ;
 if (_coI::I32 >= 1) goto coL;
 _soy::I32 = I32[Sp + 4] + 1;
 _soz::I32 = I32[Sp + 0] - 1;
 I32[Sp + 4] = _soy::I32;
 I32[Sp + 0] = _soz::I32;
 jump FooBar_zdwfoo_info ();
 coL:
 R1 = I32[Sp + 4];
 Sp = Sp + 8;
 jump (I32[Sp + 0]) ();
 }}}
 for foo. The asm:
 {{{
 FooBar_zdwbar_info:
 .LcnT:
 movl 0(%ebp),%eax
 testl %eax,%eax
 jne .LcnX
 movl 4(%ebp),%esi
 addl $8,%ebp
 jmp *0(%ebp)
 .LcnX:
 decl %eax
 incl 4(%ebp)
 movl %eax,0(%ebp)
 jmp FooBar_zdwbar_info
 }}}
 resp.
 {{{
 FooBar_zdwfoo_info:
 .Lcpe:
 cmpl $0,0(%ebp)
 jle .Lcph
 movl 0(%ebp),%eax
 decl %eax
 incl 4(%ebp)
 movl %eax,0(%ebp)
 jmp FooBar_zdwfoo_info
 .Lcph:
 movl 4(%ebp),%esi
 addl $8,%ebp
 jmp *0(%ebp)
 }}}
 doesn't tell me either why bar is faster than foo.

-- 
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] #915: Implement list fusion using streams instead of foldr/build

2011-05-16 Thread GHC
#915: Implement list fusion using streams instead of foldr/build
-+--
Reporter:  simonpj   |Owner:
Type:  task  |   Status:  new   
Priority:  low   |Milestone:  7.2.1 
   Component:  libraries/base|  Version:  6.8   
Keywords:  fusion| Testcase:  N/A   
   Blockedby:|   Difficulty:  Project (more than a week)
  Os:  Unknown/Multiple  | Blocking:
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown  
-+--
Changes (by spl):

 * cc: leather@… (added)


-- 
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] #915: Implement list fusion using streams instead of foldr/build

2011-05-16 Thread GHC
#915: Implement list fusion using streams instead of foldr/build
-+--
Reporter:  simonpj   |Owner:
Type:  task  |   Status:  new   
Priority:  low   |Milestone:  7.2.1 
   Component:  libraries/base|  Version:  6.8   
Keywords:  fusion| Testcase:  N/A   
   Blockedby:|   Difficulty:  Project (more than a week)
  Os:  Unknown/Multiple  | Blocking:
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown  
-+--
Changes (by jmcarthur):

 * cc: Jake.McArthur@… (added)


-- 
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] #4434: barton-mangler-bug failed with timeout (multiple ways)

2011-05-16 Thread GHC
#4434: barton-mangler-bug failed with timeout (multiple ways)
--+-
Reporter:  daniel.is.fischer  |Owner:  
Type:  bug|   Status:  new 
Priority:  normal |Milestone:  7.2.1   
   Component:  Compiler   |  Version:  7.1 
Keywords: | Testcase:  
   Blockedby: |   Difficulty:  
  Os:  Linux  | Blocking:  
Architecture:  x86|  Failure:  Compile-time performance bug
--+-

Comment(by daniel.is.fischer):

 Hasn't failed for months, I think we can close this ticket for the time
 being.

-- 
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] #4435: T3016 failed with timeout (hpc and optasm)

2011-05-16 Thread GHC
#4435: T3016 failed with timeout (hpc and optasm)
--+-
Reporter:  daniel.is.fischer  |Owner:  
Type:  bug|   Status:  new 
Priority:  normal |Milestone:  7.2.1   
   Component:  Compiler   |  Version:  7.1 
Keywords: | Testcase:  
   Blockedby: |   Difficulty:  
  Os:  Linux  | Blocking:  
Architecture:  x86|  Failure:  Compile-time performance bug
--+-

Comment(by daniel.is.fischer):

 Doesn't fail anymore, I think we can close this ticket. If it starts to
 fail again, I'd reopen this or create a new ticket.

-- 
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] #2370: num009 fails on OS X 10.5?

2011-05-16 Thread GHC
#2370: num009 fails on OS X 10.5?
---+
Reporter:  batterseapower  |Owner:
Type:  bug |   Status:  new   
Priority:  low |Milestone:  7.2.1 
   Component:  Compiler|  Version:  6.9   
Keywords:  | Testcase:  lib/Numeric/num009
   Blockedby:  |   Difficulty:  Unknown   
  Os:  MacOS X | Blocking:
Architecture:  x86_64 (amd64)  |  Failure:  None/Unknown  
---+

Comment(by batterseapower):

 It's expect_broken in db60d4c323b9c3fc1b5ed6c5b0547d894d324da7

-- 
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] #5200: Ignore files generated while running tests

2011-05-16 Thread GHC
#5200: Ignore files generated while running tests
--+-
 Reporter:  tibbe |  Owner:  
 Type:  bug   | Status:  closed  
 Priority:  normal|  Component:  Build System
  Version:  7.1   | Resolution:  fixed   
 Keywords:|   Testcase:  
Blockedby:| Os:  Unknown/Multiple
 Blocking:|   Architecture:  Unknown/Multiple
  Failure:  None/Unknown  |  
--+-
Changes (by batterseapower):

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


Comment:

 Done in decc77b1b2c9e340b3fa6e5405b70a64467c477b

-- 
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] #5077: Tests failing due to different type variables in the diagnostics

2011-05-16 Thread GHC
#5077: Tests failing due to different type variables in the diagnostics
---+
 Reporter:  daniel.is.fischer  |  Owner:  
 Type:  bug| Status:  closed  
 Priority:  normal |  Component:  Test Suite  
  Version:  7.0.3  | Resolution:  fixed   
 Keywords: |   Testcase:  
Blockedby: | Os:  Unknown/Multiple
 Blocking: |   Architecture:  Unknown/Multiple
  Failure:  None/Unknown   |  
---+
Changes (by daniel.is.fischer):

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


Comment:

 Expected stderr updated, closing.

-- 
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] #5079: T3330a: wrong stderr output (new type checking algorithm?)

2011-05-16 Thread GHC
#5079: T3330a: wrong stderr output (new type checking algorithm?)
---+
 Reporter:  daniel.is.fischer  |  Owner:  
 Type:  bug| Status:  closed  
 Priority:  normal |  Component:  Test Suite  
  Version:  7.0.3  | Resolution:  fixed   
 Keywords: |   Testcase:  
Blockedby: | Os:  Unknown/Multiple
 Blocking: |   Architecture:  Unknown/Multiple
  Failure:  None/Unknown   |  
---+
Changes (by daniel.is.fischer):

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


Comment:

 Expected stderr was adapted, closing.

-- 
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] #5081: Unexpected passes arrows and ghci, typecheck and ghci

2011-05-16 Thread GHC
#5081: Unexpected passes arrows and ghci, typecheck and ghci
---+
 Reporter:  daniel.is.fischer  |  Owner:
 Type:  bug| Status:  closed
 Priority:  normal |  Component:  Test Suite
  Version:  7.0.3  | Resolution:  fixed 
 Keywords: |   Testcase:
Blockedby: | Os:  Linux 
 Blocking: |   Architecture:  x86   
  Failure:  None/Unknown   |  
---+
Changes (by daniel.is.fischer):

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


Comment:

 No longer expected to fail, closing.

-- 
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] #5100: Stack space overflow when using -N2 and not with -N1

2011-05-16 Thread GHC
#5100: Stack space overflow when using -N2 and not with -N1
---+
Reporter:  mitar   |   Owner:   
Type:  bug |  Status:  new  
Priority:  normal  |   Component:  libraries (other)
 Version:  7.1 |Keywords:   
Testcase:  |   Blockedby:   
  Os:  Linux   |Blocking:   
Architecture:  x86_64 (amd64)  | Failure:  None/Unknown 
---+
Changes (by daniel.is.fischer):

  * component:  Compiler => libraries (other)


-- 
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] #5100: Stack space overflow when using -N2 and not with -N1

2011-05-16 Thread GHC
#5100: Stack space overflow when using -N2 and not with -N1
---+
Reporter:  mitar   |   Owner:  
Type:  bug |  Status:  new 
Priority:  normal  |   Component:  Compiler
 Version:  7.1 |Keywords:  
Testcase:  |   Blockedby:  
  Os:  Linux   |Blocking:  
Architecture:  x86_64 (amd64)  | Failure:  None/Unknown
---+

Comment(by daniel.is.fischer):

 Definitely a bug.
 {{{
 parListChunk :: Int -> Strategy a -> Strategy [a]
 parListChunk n strat xs =
   concat `fmap` parList (evalList strat) (chunk n xs)

 chunk :: Int -> [a] -> [[a]]
 chunk _ [] = []
 chunk n xs = as : chunk n bs where (as,bs) = splitAt n xs
 }}}
 means that `parListChunk 0 strat xs` evaluates an infinity of empty lists
 in parallel.
 Either parListChunk or chunk should ensure that the chunks are non-empty.
 Since `chunk` is not exported and used only by `parListChunk`, having the
 latter call `chunk (max 1 n) xs` would avoid re-checking the chunksize in
 each recursive step.

-- 
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] #5004: loading stripped libHsghc-7.0.2.a fails

2011-05-16 Thread GHC
#5004: loading stripped libHsghc-7.0.2.a fails
-+--
  Reporter:  pbrisbin|  Owner:  duncan  
  Type:  bug | Status:  closed  
  Priority:  highest |  Milestone:  7.2.1   
 Component:  Compiler|Version:  7.0.2   
Resolution:  fixed   |   Keywords:  
  Testcase:  |  Blockedby:  
Difficulty:  | Os:  Linux   
  Blocking:  |   Architecture:  Unknown/Multiple
   Failure:  GHCi crash  |  
-+--
Changes (by duncan):

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


Comment:

 Now applied to the 7.0.x branch too.

-- 
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] #4359: Implement lambda-case/lambda-if

2011-05-16 Thread GHC
#4359: Implement lambda-case/lambda-if
-+--
Reporter:  batterseapower|Owner:  
Type:  feature request   |   Status:  new 
Priority:  high  |Milestone:  7.2.1   
   Component:  Compiler  |  Version:  7.1 
Keywords:| Testcase:  
   Blockedby:|   Difficulty:  
  Os:  Unknown/Multiple  | Blocking:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--

Comment(by mikhail.vorozhtsov):

 Enabled guards.

-- 
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] #2370: num009 fails on OS X 10.5?

2011-05-16 Thread GHC
#2370: num009 fails on OS X 10.5?
---+
Reporter:  batterseapower  |Owner:
Type:  bug |   Status:  new   
Priority:  low |Milestone:  7.2.1 
   Component:  Compiler|  Version:  6.9   
Keywords:  | Testcase:  lib/Numeric/num009
   Blockedby:  |   Difficulty:  Unknown   
  Os:  MacOS X | Blocking:
Architecture:  x86_64 (amd64)  |  Failure:  None/Unknown  
---+

Comment(by simonmar):

 So could someone mark it as an expected failure on OS X please?

-- 
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] #5199: linkBCO: >= 64k insns in BCO

2011-05-16 Thread GHC
#5199: linkBCO: >= 64k insns in BCO
---+
  Reporter:  depe  |  Owner:
  Type:  bug   | Status:  closed
  Priority:  normal|  Milestone:
 Component:  Compiler  |Version:  6.10.4
Resolution:  duplicate |   Keywords:
  Testcase:|  Blockedby:
Difficulty:| Os:  FreeBSD   
  Blocking:|   Architecture:  x86_64 (amd64)
   Failure:  None/Unknown  |  
---+
Changes (by simonmar):

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


Comment:

 Thanks for the report.  Fixed in 6.12.1; see #789

-- 
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] #5194: "Fix build" broke build?

2011-05-16 Thread GHC
#5194: "Fix build" broke build?
-+--
 Reporter:  daniel.is.fischer|  Owner:  benl
 Type:  bug  | Status:  closed  
 Priority:  normal   |  Component:  Compiler
  Version:  7.1  | Resolution:  fixed   
 Keywords:   |   Testcase:  
Blockedby:   | Os:  Linux   
 Blocking:   |   Architecture:  x86 
  Failure:  Building GHC failed  |  
-+--
Changes (by daniel.is.fischer):

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


Comment:

 Fixed by changeset:a36cd6377ee2a65537fc02b78015937b50a69286

-- 
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] #5133: Random instance for Float can generate values out of requested range

2011-05-16 Thread GHC
#5133: Random instance for Float can generate values out of requested range
-+--
Reporter:  richardsenington  |   Owner:
Type:  bug   |  Status:  new   
Priority:  normal|   Component:  libraries/base
 Version:  7.1   |Keywords:  System.Random 
Testcase:|   Blockedby:
  Os:  Linux |Blocking:
Architecture:  x86   | Failure:  None/Unknown  
-+--

Comment(by daniel.is.fischer):

 Adding a check for a return value of 1.0 and replacing that with 0.0 (so
 that all `Float` results are rounded to from approximately the same number
 of `Double` results - the round-to-even strategy makes the numbers not
 quite identical) doesn't cost much performance, actually I found no
 consistently measurable slowdown in my benchmarks.
 But I'm not entirely sure that it works reliably,
 {{{
 case realToFrac y of
   x -> x - int2Float (float2Int x)
 }}}
 failed due to using extended precision (so the result of realToFrac wasn't
 really 1.0, float2Int x was 0, result finally rounded to 1 anyway) when
 compiled with optimisations but without -msse2.
 I don't know whether that can also happen with
 {{{
 case realToFrac y of
   1.0 -> 0.0
   x   -> x
 }}}
 It would take someone who knows what's actually going on in the FPU (and
 code generator).

-- 
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] #5004: loading stripped libHsghc-7.0.2.a fails

2011-05-16 Thread GHC
#5004: loading stripped libHsghc-7.0.2.a fails
-+--
Reporter:  pbrisbin  |Owner:  duncan
Type:  bug   |   Status:  new   
Priority:  highest   |Milestone:  7.2.1 
   Component:  Compiler  |  Version:  7.0.2 
Keywords:| Testcase:
   Blockedby:|   Difficulty:
  Os:  Linux | Blocking:
Architecture:  Unknown/Multiple  |  Failure:  GHCi crash
-+--

Comment(by simonmar):

 Patch looks fine as far as I can tell.  Nice job!

-- 
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] #5179: Unexpected Failure due to change of defaultDynFlags' type

2011-05-16 Thread GHC
#5179: Unexpected Failure due to change of defaultDynFlags' type
--+-
Reporter:  daniel.is.fischer  |Owner:  igloo
Type:  bug|   Status:  new  
Priority:  high   |Milestone:  7.2.1
   Component:  Test Suite |  Version:  7.1  
Keywords: | Testcase:   
   Blockedby: |   Difficulty:   
  Os:  Unknown/Multiple   | Blocking:   
Architecture:  Unknown/Multiple   |  Failure:  Other
--+-

Comment(by daniel.is.fischer):

 `defaultDynFlags` now has argument `(panic "No settings")` and the test
 passes, should the ticket be closed or left open to find reasonable
 `Settings`?

-- 
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] #5200: Ignore files generated while running tests

2011-05-16 Thread GHC
#5200: Ignore files generated while running tests
-+--
Reporter:  tibbe |   Owner:  
Type:  bug   |  Status:  new 
Priority:  normal|   Component:  Build System
 Version:  7.1   |Keywords:  
Testcase:|   Blockedby:  
  Os:  Unknown/Multiple  |Blocking:  
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
-+--
 Running the test suite generates a bunch of files not currently ignored by
 git, mucking up `git status`. Please apply the attached patch that ignores
 most of them (those that can be easily ignored by extension).

-- 
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