Re: [GHC] #6066: Constraint Kinds don't work with Template Haskell

[GHC]

#6066: Constraint Kinds don't work with Template Haskell
--+-
 Reporter:  sseverance|  Owner:  
 Type:  bug   | Status:  new 
 Priority:  normal|  Component:  Compiler
  Version:  7.4.1 |   Keywords:  
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
  Failure:  None/Unknown  |   Testcase:  
Blockedby:|   Blocking:  
  Related:|  
--+-

Comment(by dreixel):

 Maybe this is also fixed with the patches for #5612?

-- 
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] #6066: Constraint Kinds don't work with Template Haskell

[GHC]

#6066: Constraint Kinds don't work with Template Haskell
--+-
 Reporter:  sseverance|  Owner:  
 Type:  bug   | Status:  new 
 Priority:  normal|  Component:  Compiler
  Version:  7.4.1 |   Keywords:  
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
  Failure:  None/Unknown  |   Testcase:  
Blockedby:|   Blocking:  
  Related:|  
--+-
 If I have a record with a constraint kind that has multiple constraints
 such as:

 {{{
 type MyConstraint a = (Show a, Eq a, Typeable a)
 data MyConstraint a => MyType a =  MyType {
   someField :: a
 }
 }}}

 If I try to use template haskell on the type (in my case mkLabels from
 fclabels) you get the following error:  Can't represent tuple predicates
 in Template Haskell: MyConstraint a

 Complete Repro Case:

 {{{
 {-# LANGUAGE ConstraintKinds #-}
 {-# LANGUAGE DatatypeContexts #-}
 {-# LANGUAGE ExistentialQuantification #-}
 {-# LANGUAGE TemplateHaskell #-}

 import Data.Label
 import Data.Typeable

 type MyConstraint a = (Show a, Eq a, Typeable a)

 data MyConstraint a => MyType a = MyType {
   myField :: a
 } deriving (Show, Eq)

 mkLabels [''MyType]
 }}}

-- 
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] #6065: Suggested type signature causes a type error (even though it appears correct)

[GHC]

#6065: Suggested type signature causes a type error (even though it appears
correct)
---+
 Reporter:  tvynr  |  Owner:
  
 Type:  bug| Status:  new   
  
 Priority:  normal |  Component:  Compiler (Type 
checker) 
  Version:  7.4.1  |   Keywords:  type signature 
typeclass instance forall
   Os:  Linux  |   Architecture:  x86_64 (amd64)
  
  Failure:  GHC rejects valid program  |   Testcase:
  
Blockedby: |   Blocking:
  
  Related: |  
---+
 The attached file, MWE.hs, contains an experiment attempting a rudimentary
 encoding of extensible ASTs in Haskell (without using compdata or a
 similar package relying upon OverlappingInstances and so forth).  The
 definition of the upcast function appears to be correct.  Compiling
 without a type signature produces a warning and the suggestion to include
 a type signature.  Including the suggested type signature (which appears
 to be the correct one) causes a type error.

-- 
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] #6064: InstanceD declaration does not allow for explicit TyVarBndrs

[GHC]

#6064: InstanceD declaration does not allow for explicit TyVarBndrs
--+-
 Reporter:  goldfire  |  Owner:   
 Type:  feature request   | Status:  new  
 Priority:  normal|  Component:  Template Haskell 
  Version:  7.5   |   Keywords:  TemplateHaskell InstanceD
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple 
  Failure:  None/Unknown  |   Testcase:   
Blockedby:|   Blocking:   
  Related:|  
--+-
 The definition of {{{InstanceD}}} does not allow for explicitly-kinded
 type variables. Though it is possible to use {{{SigT}}} to give kinds in
 places, GHC currently does not allow undeclared kind variables to appear
 there.

 I propose changing the definition of {{{InstanceD}}} to be as follows:

 {{{
 type Dec =
   ...
   | InstanceD [TyVarBndr] Cxt Type [Dec]
   ...
 }}}

-- 
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] #5642: Deriving Generic of a big type takes a long time and lots of space

[GHC]

#5642: Deriving Generic of a big type takes a long time and lots of space
-+--
Reporter:  basvandijk|   Owner:  dimitris
Type:  bug   |  Status:  new 
Priority:  high  |   Milestone:  7.6.1   
   Component:  Compiler  | Version:  7.3 
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  Compile-time performance bug
  Difficulty:  Unknown   |Testcase:  T5642   
   Blockedby:|Blocking:  
 Related:|  
-+--
Changes (by simonpj):

 * cc: dimitris@… (added)
  * milestone:  7.4.2 => 7.6.1


Comment:

 There is still something odd here.  Here's the output for HEAD, doing `ghc
 T5642.hs -dshow-passes +RTS -s`, for various sizes of input data type.  If
 you do it yourself you'll see that 99% of the time is spent in the
 typechecker.  The rest of compilation is fast.

 So not only is it non-linear but the constant factor is terrible.  It just
 can't take that long to typecheck this stuff!

 I'm punting for 7.4, but we need to look again for 7.6.

 Simon

 ---
 100 constructors
 {{{
 simonpj@cam-05-unx:~/tmp$ ~/5builds/HEAD/inplace/bin/ghc-stage2 -c
 T5642.hs -dshow-passes +RTS -s
 Glasgow Haskell Compiler, Version 7.5, stage 2 booted by GHC version 7.4.1
 *** Checking old interface for main:T5642:
 *** Parser:
 *** Renamer/typechecker:
 *** Desugar:
 Result size of Desugar (after optimization)
   = {terms: 3,498, types: 160,413, coercions: 1,305}
 *** Simplifier:
 Result size of Simplifier iteration=1
   = {terms: 3,298, types: 110,113, coercions: 51,906}
 Result size of Simplifier
   = {terms: 3,298, types: 110,113, coercions: 51,805}
 *** Tidy Core:
 Result size of Tidy Core
   = {terms: 3,298, types: 110,113, coercions: 51,805}
 *** CorePrep:
 Result size of CorePrep
   = {terms: 4,642, types: 159,413, coercions: 51,805}
 *** Stg2Stg:
 *** CodeGen:
 *** CodeOutput:
 *** Assembler:
 *** Deleting temp files:
 Warning: deleting non-existent /tmp/ghc46808_0/ghc46808_0.c
 *** Deleting temp dirs:
3,189,810,752 bytes allocated in the heap
1,176,054,736 bytes copied during GC
   70,837,720 bytes maximum residency (19 sample(s))
1,225,552 bytes maximum slop
  158 MB total memory in use (0 MB lost due to fragmentation)

 Tot time (elapsed)  Avg pause  Max
 pause
   Gen  0  6039 colls, 0 par1.99s1.99s 0.0003s
 0.0038s
   Gen  119 colls, 0 par1.45s1.45s 0.0761s
 0.2469s

   TASKS: 3 (1 bound, 2 peak workers (2 total), using -N1)

   SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled)

   INITtime0.00s  (  0.00s elapsed)
   MUT time5.86s  (  5.95s elapsed)
   GC  time3.44s  (  3.43s elapsed)
   EXITtime0.00s  (  0.00s elapsed)
   Total   time9.29s  (  9.38s elapsed)

   Alloc rate544,723,338 bytes per MUT second

   Productivity  63.0% of total user, 62.4% of total elapsed
 }}}

 --
 150 constructors
 {{{
 simonpj@cam-05-unx:~/tmp$ ~/5builds/HEAD/inplace/bin/ghc-stage2 -c
 T5642.hs -dshow-passes +RTS -s
 Glasgow Haskell Compiler, Version 7.5, stage 2 booted by GHC version 7.4.1
 *** Checking old interface for main:T5642:
 *** Parser:
 *** Renamer/typechecker:
 *** Desugar:
 Result size of Desugar (after optimization)
   = {terms: 5,690, types: 401,601, coercions: 2,85}
 *** Simplifier:
 Result size of Simplifier iteration=1
   = {terms: 5,370, types: 273,121, coercions: 131,46}
 Result size of Simplifier
   = {terms: 5,370, types: 273,121, coercions: 130,885}
 *** Tidy Core:
 Result size of Tidy Core
   = {terms: 5,370, types: 273,121, coercions: 130,885}
 *** CorePrep:
 Result size of CorePrep
   = {terms: 7,738, types: 400,1, coercions: 130,885}
 *** Stg2Stg:
 *** CodeGen:
 *** CodeOutput:
 *** Assembler:
 *** Deleting temp files:
 Warning: deleting non-existent /tmp/ghc47478_0/ghc47478_0.c
 *** Deleting temp dirs:
8,336,602,152 bytes allocated in the heap
4,066,619,088 bytes copied during GC
  218,323,536 bytes maximum residency (33 sample(s))
3,689,368 bytes maximum slop
  479 MB total memory in use (0 MB lost due to fragmentation)

 Tot time (elapsed)  Avg pause  Max
 pause
   Gen  0 15893 colls, 0 par6.45s6.45s 0.0004s
 0.0033s
   Gen  133 colls, 0 par4.78s4.78s 0.1448s
 0.7436s

   TASKS: 3 (1 bound, 2 peak workers (2 total), using -N1)

   SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled)

   INITtime0.00s 

Re: [GHC] #5527: mkTopLevEnv: not interpreted

[GHC]

#5527: mkTopLevEnv: not interpreted
+---
Reporter:  cdsmith  |   Owner:  pcapriotti  
Type:  bug  |  Status:  new 
Priority:  normal   |   Milestone:  7.6.1   
   Component:  GHC API  | Version:  7.3 
Keywords:   |  Os:  Linux   
Architecture:  x86  | Failure:  None/Unknown
  Difficulty:  Unknown  |Testcase:  
   Blockedby:   |Blocking:  
 Related:   |  
+---
Changes (by pcapriotti):

  * owner:  => pcapriotti
  * difficulty:  => Unknown


-- 
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] #6063: GHC's build-time ld-flag checks are problematic

[GHC]

#6063: GHC's build-time ld-flag checks are problematic
--+-
 Reporter:  parcs |  Owner:  
 Type:  bug   | Status:  new 
 Priority:  normal|  Component:  Compiler
  Version:  7.4.1 |   Keywords:  
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
  Failure:  None/Unknown  |   Testcase:  
Blockedby:|   Blocking:  
  Related:|  
--+-
 If the linker that GHC was built against happened to recognize the
 `--hash-size` and `--reduce-memory-overhead` flags, but the current system
 linker does not, GHC will indiscriminately pass those flags to the current
 linker when attempting to link anything, and the linking will fail due to
 an 'unrecognized option' error.

 I have experienced this behavior when I upgraded to GHC 7.4.1 on debian.
 The GHC package in question was built against `bfd ld`, which recognized
 those linker flags, but my system linker is `gold`, which does not
 recognized those flags. Therefore, I could not build anything until i
 reverted to `bfd ld`.

 (Relevant commits: 3275b7bd2a803a3adc0b952b6fbfeb738fc15a74 and
 9ccb59ed6e5edf73c876e87429e69e8848162497)

-- 
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] #6060: the 'impossible' happened

[GHC]

#6060: the 'impossible' happened
-+--
Reporter:  lerkok|   Owner:
Type:  bug   |  Status:  patch 
Priority:  normal|   Milestone:  7.6.1 
   Component:  Compiler  | Version:  7.4.1 
Keywords:|  Os:  Unknown/Multiple  
Architecture:  Unknown/Multiple  | Failure:  Compile-time crash
  Difficulty:  Unknown   |Testcase:
   Blockedby:|Blocking:
 Related:|  
-+--
Changes (by pcapriotti):

  * status:  new => patch


Comment:

 The pretty printer for parallel comprehensions is broken. Attached patch
 and testcase.

-- 
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] #6054: Couldn't match kind `BOX' against `*' when using SOURCE import

[GHC]

#6054: Couldn't match kind `BOX' against `*' when using SOURCE import
---+
  Reporter:  atnnn |  Owner:  
  Type:  bug   | Status:  closed  
  Priority:  normal|  Milestone:  
 Component:  Compiler  |Version:  7.4.1   
Resolution:  fixed |   Keywords:  
Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  | Difficulty:  Unknown 
  Testcase:  polykinds/T6054   |  Blockedby:  
  Blocking:|Related:  
---+
Changes (by simonpj):

  * status:  new => closed
  * difficulty:  => Unknown
  * resolution:  => fixed
  * testcase:  => polykinds/T6054


Comment:

 Thanks for identifying this!

-- 
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] #6055: panic: ctFlavId: derived constraint cannot have id

[GHC]

#6055: panic: ctFlavId: derived constraint cannot have id
-+--
  Reporter:  Lemming |  Owner:  
  Type:  bug | Status:  closed  
  Priority:  normal  |  Milestone:  
 Component:  Compiler (Type checker) |Version:  7.5 
Resolution:  fixed   |   Keywords:  
Os:  Unknown/Multiple|   Architecture:  Unknown/Multiple
   Failure:  Compile-time crash  | Difficulty:  Unknown 
  Testcase:  typecheck/should_compile/T6055  |  Blockedby:  
  Blocking:  |Related:  
-+--
Changes (by simonpj):

  * status:  new => closed
  * difficulty:  => Unknown
  * resolution:  => fixed
  * testcase:  => typecheck/should_compile/T6055


-- 
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] #6055: panic: ctFlavId: derived constraint cannot have id

[GHC]

#6055: panic: ctFlavId: derived constraint cannot have id
+---
 Reporter:  Lemming |  Owner: 
 Type:  bug | Status:  new
 Priority:  normal  |  Component:  Compiler (Type checker)
  Version:  7.5 |   Keywords: 
   Os:  Unknown/Multiple|   Architecture:  Unknown/Multiple   
  Failure:  Compile-time crash  |   Testcase: 
Blockedby:  |   Blocking: 
  Related:  |  
+---

Comment(by simonpj@…):

 commit 081ee177f3727a4c1bfad5897cab51e30c209521
 {{{
 Author: Simon Peyton Jones 
 Date:   Mon Apr 30 16:20:01 2012 +0100

 Egregious typo (fixes Trac #6055)

  compiler/typecheck/TcInteract.lhs |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 }}}

-- 
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] #6061: threadDelay broken on Windows

[GHC]

#6061: threadDelay broken on Windows
-+--
Reporter:  simonmar  |   Owner:  pcapriotti  
Type:  bug   |  Status:  patch   
Priority:  highest   |   Milestone:  7.6.1   
   Component:  Compiler  | Version:  7.4.1   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--
Changes (by pcapriotti):

  * status:  new => patch


Comment:

 I realized that we can actually work around the clock skew issue by
 calculating the delay target directly in the IO manager thread, assuming
 it always wakes up promptly enough to make the difference in timing
 negligible.

 The attached patch fixes the `ThreadDelay001` test for me.

-- 
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] #6062: TH treats non-functions in function position inconsistently

[GHC]

#6062: TH treats non-functions in function position inconsistently
--+-
 Reporter:  heisenbug |  Owner:  
 Type:  bug   | Status:  new 
 Priority:  normal|  Component:  Compiler
  Version:  7.5   |   Keywords:  
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
  Failure:  None/Unknown  |   Testcase:  
Blockedby:|   Blocking:  
  Related:|  
--+-
 I start GHCi like this:
 {{{
 ~/bin/ghci -XTemplateHaskell
 }}}

 My aim is to use TH to rewrite certain application-looking (syntactically)
 constructs to semantically valid haskell code, that passes the type-
 checker (c.f. Conor McBride's "idiom brackets").

 But I already fail at very simple things, because GHC seems to type-check
 the TH quotation's innards...

 This works:
 {{{
 Prelude> :t [| id id |]
 [| id id |]
   :: Language.Haskell.TH.Syntax.Q Language.Haskell.TH.Syntax.Exp
 }}}

 This is also accepted, though it is clearly not typeable:
 {{{
 Prelude> :t [| 1 1 |]
 [| 1 1 |]
   :: Language.Haskell.TH.Syntax.Q Language.Haskell.TH.Syntax.Exp
 }}}

 Encouraged by this I try:
 {{{
 Prelude> :t [| False True |]
 :1:4:
 Couldn't match expected type `Bool -> t0' with actual type `Bool'
 The function `False' is applied to one argument,
 but its type `Bool' has none
 In the Template Haskell quotation [| False True |]
 In the expression: [| False True |]
 }}}

 Bummer! Somehow the type-checker does get into business with "expressions"
 inside quotations.

 I believe this is a bug, and a quotation should be built for {{{[| False
 True |]}}} in spite of {{{False True}}} not being typeable.

 I know that using quasi-quotations I can build my own parser and rewrite
 engine around this, but that is a tad heavyweight for me and I'd like to
 understand the root of the above inconsistency and why the type checker
 gets active in some cases above, but not in others.

-- 
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] #6061: threadDelay broken on Windows

[GHC]

#6061: threadDelay broken on Windows
-+--
Reporter:  simonmar  |   Owner:  pcapriotti  
Type:  bug   |  Status:  new 
Priority:  highest   |   Milestone:  7.6.1   
   Component:  Compiler  | Version:  7.4.1   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--

Comment(by pcapriotti):

 I think this is due to clock skew among different CPUs when using QPC. The
 skew itself shouldn't be very large (up to 5 μs on my system), so it's not
 a concern for the purpose of `threadDelay`, but it does break the
 invariant that the actual delay time is greater or equal to the requested
 time. Maybe we could just change the test and add a few μs tolerance.

 I'm not sure why you saw `threadDelay 100` return immediately. I
 haven't been able to reproduce that here. Maybe the clock skew can got
 over 1 second somehow? That would mean we can't really rely on
 `QueryPerformanceCounter`.

-- 
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] #6054: Couldn't match kind `BOX' against `*' when using SOURCE import

[GHC]

#6054: Couldn't match kind `BOX' against `*' when using SOURCE import
--+-
 Reporter:  atnnn |  Owner:  
 Type:  bug   | Status:  new 
 Priority:  normal|  Component:  Compiler
  Version:  7.4.1 |   Keywords:  
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
  Failure:  None/Unknown  |   Testcase:  
Blockedby:|   Blocking:  
  Related:|  
--+-

Comment(by simonpj@…):

 commit e57c8667363a60164b3505f22ddd25a9d5be32f5
 {{{
 Author: Simon Peyton Jones 
 Date:   Mon Apr 30 13:40:23 2012 +0100

 Make the interface-file deserialisation work right for promoted types
 (Trac #6054)

 GHC currently uses the slightly-dodgy plan that when we proote
 a TyCon to be a Kind constructor we leave it with the same Name.

 That means that to make sense of a IfaceType we need to know wheter
 it is really an IfaceType or an IfaceKind, because in the latter an
 occurrence of (say) Maybe will be the *promoted* Maybe.

 See Note [Checking IfaceTypes vs IfaceKinds] in TcIface

  compiler/iface/TcIface.lhs |   73
 +++
  1 files changed, 66 insertions(+), 7 deletions(-)
 }}}

-- 
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] #6055: panic: ctFlavId: derived constraint cannot have id

[GHC]

#6055: panic: ctFlavId: derived constraint cannot have id
+---
 Reporter:  Lemming |  Owner: 
 Type:  bug | Status:  new
 Priority:  normal  |  Component:  Compiler (Type checker)
  Version:  7.5 |   Keywords: 
   Os:  Unknown/Multiple|   Architecture:  Unknown/Multiple   
  Failure:  Compile-time crash  |   Testcase: 
Blockedby:  |   Blocking: 
  Related:  |  
+---
Changes (by mikhail.vorozhtsov):

 * cc: mikhail.vorozhtsov@… (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] #6061: threadDelay broken on Windows

[GHC]

#6061: threadDelay broken on Windows
-+--
Reporter:  simonmar  |   Owner:  pcapriotti  
Type:  bug   |  Status:  new 
Priority:  highest   |   Milestone:  7.6.1   
   Component:  Compiler  | Version:  7.4.1   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--
Changes (by pcapriotti):

  * owner:  => pcapriotti


Comment:

 I can't reproduce the first two failures.

 The `ThreadDelay001` test is failing because `threadDelay` sometimes
 sleeps for slightly less time than requested. I'm looking into that.

-- 
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] #6061: threadDelay broken on Windows

[GHC]

#6061: threadDelay broken on Windows
-+--
Reporter:  simonmar  |   Owner:  
Type:  bug   |  Status:  new 
Priority:  highest   |   Milestone:  7.6.1   
   Component:  Compiler  | Version:  7.4.1   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--
 There seems to be new breakage in `threadDelay` on Windows.  I noticed
 `conc070` failing in a validate:

 {{{
 => conc070(ghci) 191 of 3265 [0, 0, 0]

 cd ./concurrent/should_run && 'c:/simonmar/ghc-
 validate/bindisttest/install   dir/bin/ghc.exe' -fforce-recomp -dcore-lint
 -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts  -fno-ghci-
 history conc070.hs --interactive -v0 -ignore-dot-ghci +RTS -I0.1 -RTS
 conc070.interp.stdout 2>conc070.interp.stderr

 Actual stdout output differs from expected:

 --- ./concurrent/should_run/conc070.stdout  2011-08-02 14:43:53 +0100
 +++ ./concurrent/should_run/conc070.run.stdout  2012-04-27 10:54:04 +0100
 @@ -1 +1 @@
 -[ThreadBlocked BlockedOnMVar,ThreadBlocked
 BlockedOnMVar,ThreadRunning,ThreadFinished]
 +[ThreadFinished,ThreadBlocked BlockedOnMVar,ThreadRunning,ThreadFinished]

 *** unexpected failure for conc070(ghci)
 }}}

 and strangely if you try `threadDelay 100` in GHCi it returns
 immediately.

 This test is also failing:

 {{{
 => ThreadDelay001(threaded1) 7 of 7 [0, 0, 0]
 cd . && 'c:/simonmar/ghc-validate/inplace/bin/ghc-stage2.exe' -fforce-
 recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf
 -rtsopts  -fno-ghci-history -o ThreadDelay001 ThreadDelay001.hs -threaded
 -debug   >ThreadDelay001.comp.stderr 2>&1
 cd . && ./ThreadDelay001ThreadDelay001.run.stdout
 2>ThreadDelay001.run.stderr
 Actual stdout output differs from expected:
 --- /dev/null   2012-04-30 11:17:41 +0100
 +++ ./ThreadDelay001.run.stdout 2012-04-30 11:17:41 +0100
 @@ -0,0 +1,2 @@
 +(Mon Apr 30 11:17:29 GMT Daylight Time 2012,Mon Apr 30 11:17:29 GMT
 Daylight Time 2012,100,0,-100,-1.0e-6)
 +(Mon Apr 30 11:17:29 GMT Daylight Time 2012,Mon Apr 30 11:17:29 GMT
 Daylight Time 2012,500,0,-500,-5.0e-6)
 *** unexpected failure for ThreadDelay001(threaded1)
 }}}

 Possibly related to the fix for #5865

-- 
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] #5958: Follow mtl upstream

[GHC]

#5958: Follow mtl upstream
-+--
Reporter:  igloo |   Owner:  igloo   
Type:  task  |  Status:  new 
Priority:  high  |   Milestone:  7.6.1   
   Component:  Build System  | Version:  7.4.1   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--

Comment(by simonpj):

 Do the reverse for Hoopl: make GHC's repo the master.  (Check with
 Norman.)

-- 
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] #5958: Follow mtl upstream

[GHC]

#5958: Follow mtl upstream
-+--
Reporter:  igloo |   Owner:  igloo   
Type:  task  |  Status:  new 
Priority:  high  |   Milestone:  7.6.1   
   Component:  Build System  | Version:  7.4.1   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--
Changes (by simonpj):

  * owner:  => igloo


Comment:

 Similarly Cabal, which has moved to github.

  * Add to sync-all script to warn about old repo

 Ian will do this.

-- 
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] #5977: Allow ignoring global package db

[GHC]

#5977: Allow ignoring global package db
-+--
Reporter:  duncan|   Owner:  pcapriotti  
Type:  feature request   |  Status:  new 
Priority:  high  |   Milestone:  7.6.1   
   Component:  Compiler  | Version:  7.4.1   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--
Changes (by simonpj):

  * owner:  => pcapriotti


-- 
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] #5967: incompatible implicit declaration of function 'memcpy'

[GHC]

#5967: incompatible implicit declaration of function 'memcpy'
-+--
Reporter:  nomeata   |   Owner:  pcapriotti  
Type:  bug   |  Status:  new 
Priority:  high  |   Milestone:  7.4.2   
   Component:  Compiler  | Version:  7.4.1   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  Other   
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--
Changes (by simonpj):

  * owner:  => pcapriotti


-- 
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] #5899: RTS crash w/ strange closure type 603975781 on OS X 10.8

[GHC]

#5899: RTS crash w/ strange closure type 603975781 on OS X 10.8
---+
Reporter:  dylukes |   Owner:   

Type:  bug |  Status:  new  

Priority:  high|   Milestone:  
7.4.2
   Component:  Runtime System  | Version:  
7.4.1
Keywords:  rts, strange closure, internal error, os x  |  Os:  
MacOS X  
Architecture:  x86_64 (amd64)  | Failure:  
Runtime crash
  Difficulty:  Unknown |Testcase:   

   Blockedby:  |Blocking:   

 Related:  |  
---+
Changes (by simonpj):

 * cc: gdr@… (added)


Comment:

 We seem stuck here.  Mabye it's even a linker bug.
  * It is documented not to do this
  * Surely other systems also rely on the linker not randomly re-laying out
 code

 We could do with help from a linker expert.  Gaby dos Reis perhaps?

 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] #5888: Performance regression in 7.4.1 compared to 6.12.3

[GHC]

#5888: Performance regression in 7.4.1 compared to 6.12.3
-+--
Reporter:  nickie|   Owner:  igloo  
Type:  bug   |  Status:  new
Priority:  highest   |   Milestone:  7.6.1  
   Component:  Compiler  | Version:  7.4.1  
Keywords:|  Os:  Unknown/Multiple   
Architecture:  Unknown/Multiple  | Failure:  Runtime performance bug
  Difficulty:  Unknown   |Testcase: 
   Blockedby:|Blocking: 
 Related:|  
-+--
Changes (by simonpj):

  * owner:  => igloo
  * priority:  high => highest
  * milestone:  7.4.2 => 7.6.1


Comment:

 Ian will do this for 7.6.1.

  * `CorePrep`: initialise the `CorePrepEnv` with a single (!) binding for
 `mkIntegegerId` or whatever it is.

  * Remove `Id` from `LitInteger`.

  * The `ru_try` field of `BuiltInRule` gets a new field `Name -> Id`,
 where we can look up known-key things (only!).

  * Then add rules for `Integer/Int` equality etc.  Use commutativity to
 avoid exploding the number of primops.

-- 
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] #5859: unsafeInterleaveIO duplicates computation when evaluated by multiple threads

[GHC]

#5859: unsafeInterleaveIO duplicates computation when evaluated by multiple
threads
-+--
Reporter:  joeyadams |   Owner:  simonpj
Type:  bug   |  Status:  new
Priority:  high  |   Milestone:  7.4.2  
   Component:  libraries/base| Version:  7.2.2  
Keywords:|  Os:  Unknown/Multiple   
Architecture:  Unknown/Multiple  | Failure:  Incorrect result at runtime
  Difficulty:  Unknown   |Testcase: 
   Blockedby:|Blocking: 
 Related:|  
-+--

Comment(by simonpj):

 Cf #5943

-- 
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] #5943: Code without MVar: "thread blocked indefinitely in an MVar operation"

[GHC]

#5943: Code without MVar: "thread blocked indefinitely in an MVar operation"
---+
  Reporter:  cobb  |  Owner:  simonmar
  Type:  bug   | Status:  closed  
  Priority:  high  |  Milestone:  7.4.2   
 Component:  Compiler  |Version:  7.4.1   
Resolution:  fixed |   Keywords:  
Os:  Linux |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  | Difficulty:  Unknown 
  Testcase:|  Blockedby:  
  Blocking:|Related:  
---+

Comment(by simonpj):

 Comments from the commit
 {{{
 -- We used to believe that INLINE on unsafeInterleaveIO was safe,
 -- because the state from this IO thread is passed explicitly to the
 -- interleaved IO, so it cannot be floated out and shared.
 --
 -- HOWEVER, if the compiler figures out that r is used strictly here,
 -- then it will eliminate the thunk and the side effects in m will no
 -- longer be shared in the way the programmer was probably expecting,
 -- but can be performed many times.  In #5943, this broke our
 -- definition of fixIO, which contains
 --
 --ans <- unsafeInterleaveIO (takeMVar m)
 --
 -- after inlining, we lose the sharing of the takeMVar, so the second
 -- time 'ans' was demanded we got a deadlock.  We could fix this with
 -- a readMVar, but it seems wrong for unsafeInterleaveIO to sometimes
 -- share and sometimes not (plus it probably breaks the noDuplicate).
 -- So now, we do not inline unsafeDupableInterleaveIO.
 }}}
 See also #5859.

-- 
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] #6041: Program hangs when run under Ubuntu Precise

[GHC]

#6041: Program hangs when run under Ubuntu Precise
+---
  Reporter:  dsf|  Owner:  
  Type:  bug| Status:  closed  
  Priority:  high   |  Milestone:  7.4.2   
 Component:  Compiler   |Version:  7.4.1   
Resolution:  worksforme |   Keywords:  
Os:  Linux  |   Architecture:  Unknown/Multiple
   Failure:  Runtime crash  | Difficulty:  Unknown 
  Testcase: |  Blockedby:  
  Blocking: |Related:  
+---
Changes (by simonmar):

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


Comment:

 I looked into it a bit, and the binary seems to contain a top-level CAF of
 the form "x = x", which obviously causes a loop when evaluated.  It's not
 clear where this came from, and without being able to reproduce it I can't
 make any further progress.  Thanks for the report - if it happens again,
 please reopen the 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] #6060: the 'impossible' happened

[GHC]

#6060: the 'impossible' happened
-+--
Reporter:  lerkok|   Owner:
Type:  bug   |  Status:  new   
Priority:  normal|   Milestone:  7.6.1 
   Component:  Compiler  | Version:  7.4.1 
Keywords:|  Os:  Unknown/Multiple  
Architecture:  Unknown/Multiple  | Failure:  Compile-time crash
  Difficulty:  Unknown   |Testcase:
   Blockedby:|Blocking:
 Related:|  
-+--
Changes (by pcapriotti):

  * difficulty:  => Unknown
  * milestone:  => 7.6.1
  * failure:  None/Unknown => Compile-time crash


Comment:

 Thanks for the report.

-- 
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] #6055: panic: ctFlavId: derived constraint cannot have id

[GHC]

#6055: panic: ctFlavId: derived constraint cannot have id
+---
 Reporter:  Lemming |  Owner: 
 Type:  bug | Status:  new
 Priority:  normal  |  Component:  Compiler (Type checker)
  Version:  7.5 |   Keywords: 
   Os:  Unknown/Multiple|   Architecture:  Unknown/Multiple   
  Failure:  Compile-time crash  |   Testcase: 
Blockedby:  |   Blocking: 
  Related:  |  
+---

Comment(by dimitris):

 My bad, I know what is going on. It's a silly mistake (but I am amazed our
 testsuite did not show this yet!). I will push the fix and add the
 testsuite in a couple of hours. Many thanks for this testcase!

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