date:20121002

Re: [GHC] #7262: directory 1.2 fails to build with base < 4.6

2012-10-02 Thread GHC

#7262: directory 1.2 fails to build with base < 4.6
--+-
 Reporter:  sopvop|  Owner: 
 Type:  bug   | Status:  patch  
 Priority:  normal|  Component:  libraries/directory
  Version:  7.4.2 |   Keywords: 
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple   
  Failure:  None/Unknown  |   Testcase: 
Blockedby:|   Blocking: 
  Related:|  
--+-
Changes (by sopvop):

  * status:  new => 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] #7191: hsc2hs can't treat absolute path correctly on Windows.

2012-10-02 Thread GHC

#7191: hsc2hs can't treat absolute path correctly on Windows.
--+-
 Reporter:  shelarcy  |  Owner:  
 Type:  bug   | Status:  patch   
 Priority:  normal|  Component:  hsc2hs  
  Version:  7.4.1 |   Keywords:  
   Os:  Windows   |   Architecture:  Unknown/Multiple
  Failure:  None/Unknown  |   Testcase:  
Blockedby:|   Blocking:  
  Related:|  
--+-

Comment(by shelarcy):

 Previous patch imports System.FilePath before System.Exit. I made newer
 patch that imports System.FilePath after System.Exit.

-- 
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] #7191: hsc2hs can't treat absolute path correctly on Windows.

2012-10-02 Thread GHC

#7191: hsc2hs can't treat absolute path correctly on Windows.
--+-
 Reporter:  shelarcy  |  Owner:  
 Type:  bug   | Status:  patch   
 Priority:  normal|  Component:  hsc2hs  
  Version:  7.4.1 |   Keywords:  
   Os:  Windows   |   Architecture:  Unknown/Multiple
  Failure:  None/Unknown  |   Testcase:  
Blockedby:|   Blocking:  
  Related:|  
--+-
Changes (by shelarcy):

 * cc: shelarcy@… (added)
  * status:  new => patch


Comment:

 Use filepath's function instead of Common.hs' function to fix this
 problem.

-- 
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] #7292: Optimization works for Word but not Word32 or Word64 (was: Optimization works for Word but now Word32 or Word64)

2012-10-02 Thread GHC

#7292: Optimization works for Word but not Word32 or Word64
-+--
 Reporter:  zuserm   |  Owner:  
 Type:  bug  | Status:  new 
 Priority:  normal   |  Component:  Compiler
  Version:  7.6.1|   Keywords:  
   Os:  Unknown/Multiple |   Architecture:  Unknown/Multiple
  Failure:  Runtime performance bug  |   Testcase:  
Blockedby:   |   Blocking:  
  Related:   |  
-+--

-- 
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] #7292: Optimization works for Word but now Word32 or Word64

2012-10-02 Thread GHC

#7292: Optimization works for Word but now Word32 or Word64
-+--
 Reporter:  zuserm   |  Owner:  
 Type:  bug  | Status:  new 
 Priority:  normal   |  Component:  Compiler
  Version:  7.6.1|   Keywords:  
   Os:  Unknown/Multiple |   Architecture:  Unknown/Multiple
  Failure:  Runtime performance bug  |   Testcase:  
Blockedby:   |   Blocking:  
  Related:   |  
-+--
 GHC 7.6.1 fails to properly optimize some code when explicitly specifying
 word size, that optimizes properly for Word.

 I have also tested this in 7.4.2 and it works properly.

 An example program:
 {{{
 import Criterion.Main
 import Control.Monad.Writer
 import Data.Bits
 import Data.List
 import Data.Word

 bitByBitCopy :: Word -> Word
 bitByBitCopy w = foldl' f 0 [0 .. bitSize w - 1]
   where f acc n = if w `testBit` n then acc `setBit` n else acc

 bitByBitCopy32 :: Word32 -> Word32
 bitByBitCopy32 w = foldl' f 0 [0 .. bitSize w - 1]
   where f acc n = if w `testBit` n then acc `setBit` n else acc

 bitByBitCopy64 :: Word64 -> Word64
 bitByBitCopy64 w = foldl' f 0 [0 .. bitSize w - 1]
   where f acc n = if w `testBit` n then acc `setBit` n else acc

 -- Bench
 wbench :: Benchmarkable b => String -> b -> Writer [Benchmark] ()
 wbench s b = tell [bench s b]

 main = defaultMain . execWriter $ do
 wbench "Word" $ nf bitByBitCopy 0
 when (bitSize (0::Word) == 32) $
 wbench "Word32" $ nf bitByBitCopy32 0
 when (bitSize (0::Word) == 64) $
 wbench "Word64" $ nf bitByBitCopy64 0
 }}}

-- 
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] #3024: Rewrite hp2ps in Haskell

2012-10-02 Thread GHC

#3024: Rewrite hp2ps in Haskell
-+--
Reporter:  SamB  |   Owner:  
Type:  task  |  Status:  new 
Priority:  normal|   Milestone:  _|_ 
   Component:  Profiling | Version:  6.10.1  
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--

Comment(by nomeata):

 I opened a separate ticket for the incomplete profile issue; if you fix
 the bug here you have probabaly fixed #7291 along with 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

[GHC] #7291: hp2ps should cope with incomplete data

2012-10-02 Thread GHC

#7291: hp2ps should cope with incomplete data
--+-
 Reporter:  nomeata   |  Owner:  
 Type:  feature request   | Status:  new 
 Priority:  normal|  Component:  Profiling   
  Version:  7.6.1 |   Keywords:  
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
  Failure:  None/Unknown  |   Testcase:  
Blockedby:|   Blocking:  
  Related:  #3024 |  
--+-
 So that it can be run while the program is generating the profiling data.

 Anyone who would reimplement hp2ps (e.g. #3024) would probably fix this
 along, but still this is an issue on its own, hence I’m opening a separate
 ticket.

 If someone feels like hacking on it, beware: hp2ps is written in C.

-- 
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] #3021: A way to programmatically insert marks into heap profiling output

2012-10-02 Thread GHC

#3021: A way to programmatically insert marks into heap profiling output
-+--
Reporter:  SamB  |   Owner:  
Type:  feature request   |  Status:  new 
Priority:  normal|   Milestone:  _|_ 
   Component:  Profiling | Version:  6.10.1  
Keywords:  profiling |  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--

Comment(by nomeata):

 JFTR: At this years HIW someone mentioned that you can insert marks into
 the eventlog, and that in the long run profiling data should also go to
 the eventlog.

-- 
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] #3769: Add manpages for programs installed alongside ghc

2012-10-02 Thread GHC

#3769: Add manpages for programs installed alongside ghc
---+
Reporter:  Minimiscience   |   Owner:   
Type:  feature request |  Status:  new  
Priority:  normal  |   Milestone:  _|_  
   Component:  Documentation   | Version:  6.12.1   
Keywords:  manpage documentation manpages  |  Os:  Unknown/Multiple 
Architecture:  Unknown/Multiple| Failure:  Documentation bug
  Difficulty:  |Testcase:   
   Blockedby:  |Blocking:   
 Related:  |  
---+
Changes (by nomeata):

 * cc: mail@… (added)


Comment:

 Replying to [comment:2 igloo]:
 > The real problem is adding the man pages in a way that doesn't
 significantly increase the maintenance burden.

 How about including it in the docbook documentation and extracting them
 from there? This is what I do with arbtt,
 http://darcs.nomeata.de/arbtt/doc/users_guide/arbtt-stats.html is both
 part of the users guide and extracted to a proper manpage.

-- 
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] #5641: The -L flag should not exist

2012-10-02 Thread GHC

#5641: The -L flag should not exist
-+--
Reporter:  augustss  |   Owner:  
Type:  bug   |  Status:  new 
Priority:  normal|   Milestone:  7.6.2   
   Component:  Profiling | Version:  7.2.1   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:|Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--
Changes (by nomeata):

 * cc: mail@… (added)


Comment:

 Does having a milestone imply that this is a desired feature and just
 waits for implementation? Might be some low hanging fruit for a bypassing
 contributor.

-- 
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] #7262: directory 1.2 fails to build with base < 4.6

2012-10-02 Thread GHC

#7262: directory 1.2 fails to build with base < 4.6
--+-
 Reporter:  sopvop|  Owner: 
 Type:  bug   | Status:  new
 Priority:  normal|  Component:  libraries/directory
  Version:  7.4.2 |   Keywords: 
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple   
  Failure:  None/Unknown  |   Testcase: 
Blockedby:|   Blocking: 
  Related:|  
--+-

Comment(by akaspin):

 Any chances to get patched on hackage? Or revert to previous? It's serious
 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] #7290: Minor documentation fix for directory

2012-10-02 Thread GHC

#7290: Minor documentation fix for directory
--+-
 Reporter:  SimonHengel   |  Owner:   
 Type:  bug   | Status:  new  
 Priority:  normal|  Component:  libraries (other)
  Version:  7.6.1 |   Keywords:   
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple 
  Failure:  None/Unknown  |   Testcase:   
Blockedby:|   Blocking:   
  Related:|  
--+-


-- 
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] #7225: "ghc -C" failed

2012-10-02 Thread GHC

#7225: "ghc -C" failed
-+--
Reporter:  guest |   Owner:  igloo 
Type:  bug   |  Status:  new   
Priority:  high  |   Milestone:  7.8.1 
   Component:  Compiler  | Version:  7.4.1 
Keywords:|  Os:  Windows   
Architecture:  x86   | Failure:  Compile-time crash
  Difficulty:  Unknown   |Testcase:
   Blockedby:|Blocking:
 Related:|  
-+--

Comment(by goldfire):

 This panic is also triggered by building GHC with the following in
 build.mk:

 {{{
 GhcLibWays = v p dyn p_dyn
 }}}

 Here is the error:
 {{{
   ...
   rts_dist_HC rts/dist/build/posix/Signals.
   rts_dist_HC rts/dist/build/posix/TTY.
   rts_dist_HC rts/dist/build/Apply.hc

 addFlag by -C on the commandline: Warning:
 The -fvia-C flag does nothing; it will be removed in a future GHC
 release
 ghc-stage1: panic! (the 'impossible' happened)
   (GHC version 7.7.20121002 for x86_64-apple-darwin):
 pipeLoop: at phase As but I wanted to stop at phase HCc
 }}}

 If it matters, I'm compiling on Mac OS 10.7.5 and using GHC 7.6.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] #2110: Rules to eliminate casted id's

2012-10-02 Thread GHC

#2110: Rules to eliminate casted id's
-+--
Reporter:  igloo |   Owner:  
Type:  feature request   |  Status:  new 
Priority:  lowest|   Milestone:  7.6.2   
   Component:  Compiler  | Version:  6.8.2   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--

Comment(by nomeata):

 No new idea on the syntax, just a small note: If this gets resolved, the
 fmap that DerivingFunctor generates should probably also automatically get
 such a RULE.

-- 
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] #7287: Primops in RULES generate warnings

2012-10-02 Thread GHC

#7287: Primops in RULES generate warnings
-+--
Reporter:  rl|   Owner:  simonpj
  
Type:  bug   |  Status:  new
  
Priority:  normal|   Milestone: 
  
   Component:  Compiler  | Version:  7.7
  
Keywords:|  Os:  Unknown/Multiple   
  
Architecture:  Unknown/Multiple  | Failure:  Incorrect warning at 
compile-time
  Difficulty:  Unknown   |Testcase: 
  
   Blockedby:|Blocking: 
  
 Related:|  
-+--
Changes (by simonpj):

  * owner:  => simonpj
  * difficulty:  => Unknown


Comment:

 I'm fixing (easy)

-- 
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] #7286: GHC doesn't optimise away primitive identity conversions

2012-10-02 Thread GHC

#7286: GHC doesn't optimise away primitive identity conversions
-+--
Reporter:  rl|   Owner:  igloo   
Type:  bug   |  Status:  new 
Priority:  high  |   Milestone:  7.8.1   
   Component:  Compiler  | Version:  7.7 
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  Compile-time performance bug
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--
Changes (by simonpj):

  * priority:  normal => high
  * milestone:  => 7.8.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] #7286: GHC doesn't optimise away primitive identity conversions

2012-10-02 Thread GHC

#7286: GHC doesn't optimise away primitive identity conversions
-+--
Reporter:  rl|   Owner:  igloo   
Type:  bug   |  Status:  new 
Priority:  normal|   Milestone:  
   Component:  Compiler  | Version:  7.7 
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  Compile-time performance bug
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--
Changes (by simonpj):

  * owner:  => igloo
  * 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

Re: [GHC] #7288: type inference fails with where clause (RankNTypes, TypeFamilies)

2012-10-02 Thread GHC

#7288: type inference fails with where clause (RankNTypes, TypeFamilies)
+---
  Reporter:  agrafix|  Owner:   
   
  Type:  bug| Status:  closed   
   
  Priority:  normal |  Milestone:   
   
 Component:  Compiler (Type checker)|Version:  7.6.1
   
Resolution:  invalid|   Keywords:  type inference, 
rankntypes, typefamilies
Os:  Unknown/Multiple   |   Architecture:  Unknown/Multiple 
   
   Failure:  GHC rejects valid program  | Difficulty:  Unknown  
   
  Testcase: |  Blockedby:   
   
  Blocking: |Related:   
   
+---

Comment(by dleuschner):

 Thanks, Simon!  I guess it looked like it was a let vs. where issue
 because the indentation suggests that the where-clause is inside the scope
 of the lambda but it isn't.  It would be nice if lambdas could have where
 bindings. :-)

 Replying to [comment:2 simonpj]:
 > Well, I'm afraid this is by design.
 >
 > With `TypeFamilies`, local let or where bindings are not generalised;
 see Section 4.2 of the
 [http://www.haskell.org/haskellwiki/Simonpj/Talk:OutsideIn OutsideIn
 paper].  So,
 >
 >  * In `myGen''` you give a type signature; and indeed `patToStruct` has
 the type you specify.
 >
 >  * In `mkGen'` the `let` is not generalised, but it's fine because it's
 only called at one type.
 >
 >  * In `mkGen`, the `where` is not generalised, and this time it does
 matter, because the (monomorphic) `patToStruct` is outside the `(\pid ->
 ...)`, which itself is specified to have the polymorphic type `GenFun Int
 [Struct]`.  So there is a skolem-escape problem:
 > {{{
 > T7288.hs:30:28:
 > Couldn't match type `m0' with `m'
 >   because type variable `m' would escape its scope
 > This (rigid, skolem) type variable is bound by
 >   a type expected by the context: GenM m => Int -> m [Struct]
 >   at T7288.hs:(28,5)-(31,25)
 > Expected type: Int -> m Struct
 >   Actual type: Int -> m0 Struct
 > Relevant bindings include
 >   patToStruct :: Int -> m0 Struct (bound at T7288.hs:33:11)
 > In the first argument of `mapM', namely `patToStruct'
 > In a stmt of a 'do' block: structs <- mapM patToStruct pats
 > In the expression:
 >   do { pats <- getPatients;
 >structs <- mapM patToStruct pats;
 >return structs }
 > }}}
 >
 > It's not a `let` vs `where` issue; the question is whether the non-
 generalised binding is outside the expression with a forall'd type.
 >
 > You can change the behaviour by adding `NoMonoLocalBinds` (after
 `TypeFamilies`) as a LANGUAGE pragma.  Then GHC tries harder, but less
 robustly and predictably.
 >
 > I wish I knew a better solution, but currently I don't.

-- 
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] #7288: type inference fails with where clause (RankNTypes, TypeFamilies)

2012-10-02 Thread GHC

#7288: type inference fails with where clause (RankNTypes, TypeFamilies)
+---
  Reporter:  agrafix|  Owner:   
   
  Type:  bug| Status:  closed   
   
  Priority:  normal |  Milestone:   
   
 Component:  Compiler (Type checker)|Version:  7.6.1
   
Resolution:  invalid|   Keywords:  type inference, 
rankntypes, typefamilies
Os:  Unknown/Multiple   |   Architecture:  Unknown/Multiple 
   
   Failure:  GHC rejects valid program  | Difficulty:  Unknown  
   
  Testcase: |  Blockedby:   
   
  Blocking: |Related:   
   
+---
Changes (by simonpj):

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


Old description:

> when using RankNTypes and TypeFamilies with polymorphic functions, type
> inference works in let but not in where clauses.
>

> {{{
> {-# LANGUAGE RankNTypes #-}
> {-# LANGUAGE TypeFamilies #-}
>
> import Control.Monad
>
> class Monad m => GenM m where
> type GenReq m :: *
>
> type GenFun a b = forall m. GenM m => a -> m b
> data GenDef a b = GenDef { name :: String, fun :: GenFun a b }
> data Gen a b = Gen
> data Struct = Struct
>
> mkGen :: forall a b. String -> GenFun a b -> GenDef a b
> mkGen = GenDef
>
> runGen :: GenM m => Gen a b -> a -> m (Maybe b)
> runGen = undefined
>
> getPatients :: GenM m => m [Int]
> getPatients = undefined
>
> -- BROKEN
> myGen :: Gen String Struct -> GenDef Int [Struct]
> myGen structGen =
> mkGen "myGen" $ \pid ->
> do pats <- getPatients
>structs <- mapM patToStruct pats
>return structs
> where
>   patToStruct pid =
>   do Just struct <- runGen structGen (show pid)
>  return struct
>
> -- WORKS
> myGen' :: Gen String Struct -> GenDef Int [Struct]
> myGen' structGen =
> mkGen "myGen" $ \pid ->
> do pats <- getPatients
>let patToStruct pid =
>do Just struct <- runGen structGen (show pid)
>   return struct
>structs <- mapM patToStruct pats
>return structs
>
> -- WORKS
> myGen'' :: Gen String Struct -> GenDef Int [Struct]
> myGen'' structGen =
> mkGen "myGen" $ \pid ->
> do pats <- getPatients
>structs <- mapM patToStruct pats
>return structs
> where
>   patToStruct :: GenM m => Int -> m Struct
>   patToStruct pid =
>   do Just struct <- runGen structGen (show pid)
>  return struct
>
> }}}

New description:

 when using `RankNTypes` and `TypeFamilies` with polymorphic functions,
 type inference works in let but not in where clauses.


 {{{
 {-# LANGUAGE RankNTypes #-}
 {-# LANGUAGE TypeFamilies #-}

 import Control.Monad

 class Monad m => GenM m where
 type GenReq m :: *

 type GenFun a b = forall m. GenM m => a -> m b
 data GenDef a b = GenDef { name :: String, fun :: GenFun a b }
 data Gen a b = Gen
 data Struct = Struct

 mkGen :: forall a b. String -> GenFun a b -> GenDef a b
 mkGen = GenDef

 runGen :: GenM m => Gen a b -> a -> m (Maybe b)
 runGen = undefined

 getPatients :: GenM m => m [Int]
 getPatients = undefined

 -- BROKEN
 myGen :: Gen String Struct -> GenDef Int [Struct]
 myGen structGen =
 mkGen "myGen" $ \pid ->
 do pats <- getPatients
structs <- mapM patToStruct pats
return structs
 where
   patToStruct pid =
   do Just struct <- runGen structGen (show pid)
  return struct

 -- WORKS
 myGen' :: Gen String Struct -> GenDef Int [Struct]
 myGen' structGen =
 mkGen "myGen" $ \pid ->
 do pats <- getPatients
let patToStruct pid =
do Just struct <- runGen structGen (show pid)
   return struct
structs <- mapM patToStruct pats
return structs

 -- WORKS
 myGen'' :: Gen String Struct -> GenDef Int [Struct]
 myGen'' structGen =
 mkGen "myGen" $ \pid ->
 do pats <- getPatients
structs <- mapM patToStruct pats
return structs
 where
   patToStruct :: GenM m => Int -> m Struct
   patToStruct pid =
   do Just struct <- runGen structGen (show pid)
  return struct

 }}}

--

Comment:

 Well, I'm afraid this is by design.

 With `TypeFamilies`, local let or where bindings are not generalised; see
 Section 4.2 of the
 [http://www.haskell.org/haskellwiki/Simonpj/Talk:OutsideIn

Re: [GHC] #5910: Holes with other constraints

2012-10-02 Thread GHC

#5910: Holes with other constraints
+---
Reporter:  xnyhps   |   Owner:  
Type:  feature request  |  Status:  new 
Priority:  high |   Milestone:  7.8.1   
   Component:  Compiler (Type checker)  | Version:  7.5 
Keywords:  holes|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple | Failure:  Other   
  Difficulty:  Unknown  |Testcase:  
   Blockedby:   |Blocking:  
 Related:   |  
+---

Comment(by simonpj):

 OK, so holes are now in HEAD.

 They lack
  * documentation
  * tests of any kind

 Two more actions:
  * '''Sean or Thijs, could you add documentation and tests?'''

  * I think the idea of allowing undefined variables to turn into holes is
 a good one; so I'll leave the ticket open for that 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] #7278: nonsensical kind variable ascription causes panic

2012-10-02 Thread GHC

#7278: nonsensical kind variable ascription causes panic
+---
Reporter:  nfrisby  |   Owner:
Type:  bug  |  Status:  merge 
Priority:  normal   |   Milestone:
   Component:  Compiler (Type checker)  | Version:  7.6.1 
Keywords:   |  Os:  Unknown/Multiple  
Architecture:  Unknown/Multiple | Failure:  Compile-time crash
  Difficulty:  Unknown  |Testcase:  polykinds/T7278   
   Blockedby:   |Blocking:
 Related:   |  
+---
Changes (by simonpj):

  * status:  new => merge
  * difficulty:  => Unknown
  * testcase:  => polykinds/T7278


Comment:

 This one can merge to 7.6 branch.

 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] #7288: type inference fails with where clause (RankNTypes, TypeFamilies)

2012-10-02 Thread GHC

#7288: type inference fails with where clause (RankNTypes, TypeFamilies)
---+
 Reporter:  agrafix|  Owner:
  
 Type:  bug| Status:  new   
  
 Priority:  normal |  Component:  Compiler (Type 
checker) 
  Version:  7.6.1  |   Keywords:  type inference, 
rankntypes, typefamilies
   Os:  Unknown/Multiple   |   Architecture:  Unknown/Multiple  
  
  Failure:  GHC rejects valid program  |   Testcase:
  
Blockedby: |   Blocking:
  
  Related: |  
---+
Changes (by dleuschner):

 * cc: leuschner@… (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] #5030: Slow type checking of type-level computation heavy code.

2012-10-02 Thread GHC

#5030: Slow type checking of type-level computation heavy code.
---+
  Reporter:  thesz |  Owner: 
  Type:  bug   | Status:  closed 
  Priority:  normal|  Milestone:  7.2.1  
 Component:  Compiler (Type checker)   |Version:  7.0.2  
Resolution:  fixed |   Keywords: 
Os:  Unknown/Multiple  |   Architecture:  x86
   Failure:  Compile-time performance bug  | Difficulty:  Unknown
  Testcase:  T5030 |  Blockedby: 
  Blocking:|Related: 
---+
Changes (by simonpj):

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


Comment:

 I think it's as good as it's going to get for now, and it's a bit of a
 corner case. The regression test (now reinstated) will keep an eye on it.

 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] #5591: Type constructor variables not injective

2012-10-02 Thread GHC

#5591: Type constructor variables not injective
-+--
  Reporter:  daniel.is.fischer   |  Owner:  
simonpj 
  Type:  bug | Status:  
closed  
  Priority:  normal  |  Milestone:  
7.6.2   
 Component:  Compiler (Type checker) |Version:  
7.2.1   
Resolution:  fixed   |   Keywords:  

Os:  Unknown/Multiple|   Architecture:  
Unknown/Multiple
   Failure:  None/Unknown| Difficulty:  
Unknown 
  Testcase:  indexed-ypes/should_compile/T5591a, T5591b  |  Blockedby:  

  Blocking:  |Related:  

-+--
Changes (by simonpj):

  * status:  new => closed
  * testcase:  => indexed-ypes/should_compile/T5591a, T5591b
  * resolution:  => fixed


Comment:

 Fixed at last; see #7205.  I added both examples as regression tests.

 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] #7205: Re-introduce left/right coercion decomposition

2012-10-02 Thread GHC

#7205: Re-introduce left/right coercion decomposition
---+
  Reporter:  simonpj   |  Owner:  
  Type:  feature request   | Status:  closed  
  Priority:  normal|  Milestone:  
 Component:  Compiler  |Version:  7.4.2   
Resolution:  fixed |   Keywords:  
Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  | Difficulty:  Unknown 
  Testcase:  gadt/T7205|  Blockedby:  
  Blocking:|Related:  
---+
Changes (by simonpj):

  * status:  new => closed
  * testcase:  => gadt/T7205
  * resolution:  => fixed


Comment:

 Done at last.

 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] #7205: Re-introduce left/right coercion decomposition

2012-10-02 Thread GHC

#7205: Re-introduce left/right coercion decomposition
-+--
Reporter:  simonpj   |   Owner:  
Type:  feature request   |  Status:  new 
Priority:  normal|   Milestone:  
   Component:  Compiler  | Version:  7.4.2   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--

Comment(by simonpj@…):

 commit af7cc9953217d74e88d4d21512e957edd8e97ec9
 {{{
 Author: Simon Peyton Jones 
 Date:   Mon Sep 17 11:34:28 2012 +0100

 Implement 'left' and 'right' coercions

 This patch finally adds 'left' and 'right' coercions back into
 GHC.  Trac #7205 gives the details.

 The main change is to add a new constructor to Coercion:

   data Coercion
 = ...
 | NthCo  Int Coercion -- OLD, still there
 | LRCo   LeftOrRight Coercion -- NEW

   data LeftOrRight = CLeft | CRight

 Plus:
   * Similar change to TcCoercion
   * Use LRCo when decomposing AppTys
   * Coercion optimisation needs to handle left/right

 The rest is just knock-on effects.

  compiler/coreSyn/CoreLint.lhs|   13 
  compiler/coreSyn/ExternalCore.lhs|3 ++
  compiler/coreSyn/MkExternalCore.lhs  |5 +++
  compiler/coreSyn/PprExternalCore.lhs |4 ++
  compiler/coreSyn/TrieMap.lhs |   22 ++---
  compiler/deSugar/DsBinds.lhs |1 +
  compiler/iface/BinIface.hs   |   14 -
  compiler/iface/IfaceType.lhs |5 ++-
  compiler/iface/TcIface.lhs   |1 +
  compiler/typecheck/TcCanonical.lhs   |   14 ++---
  compiler/typecheck/TcEvidence.lhs|   14 +++--
  compiler/typecheck/TcHsSyn.lhs   |1 +
  compiler/typecheck/TcType.lhs|1 +
  compiler/types/Coercion.lhs  |   31 +--
  compiler/types/OptCoercion.lhs   |   56
 -
  15 files changed, 152 insertions(+), 33 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] #5910: Holes with other constraints

2012-10-02 Thread GHC

#5910: Holes with other constraints
+---
Reporter:  xnyhps   |   Owner:  
Type:  feature request  |  Status:  new 
Priority:  high |   Milestone:  7.8.1   
   Component:  Compiler (Type checker)  | Version:  7.5 
Keywords:  holes|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple | Failure:  Other   
  Difficulty:  Unknown  |Testcase:  
   Blockedby:   |Blocking:  
 Related:   |  
+---

Comment(by simonpj@…):

 commit 8a9a7a8c42da3adb603f319a74e304af5e1b2128
 {{{
 Author: Simon Peyton Jones 
 Date:   Mon Sep 17 13:31:14 2012 +0100

 Add type "holes", enabled by -XTypeHoles, Trac #5910

 This single commit combines a lot of work done by
 Thijs Alkemade , plus a slew
 of subsequent refactoring by Simon PJ.

 The basic idea is
 * Add a new expression form "_", a hole, standing for a not-yet-
 written expression
 * Give a useful error message that
(a) gives the type of the hole
(b) gives the types of some enclosing value bindings that
mention the hole

 Driven by this goal I did a LOT of refactoring in TcErrors, which in
 turn
 allows us to report enclosing value bindings for other errors, not
 just
 holes.  (Thijs rightly did not attempt this!)

 The major data type change is a new form of constraint
   data Ct = ...
   | CHoleCan {
   cc_ev   :: CtEvidence,
   cc_hole_ty  :: TcTauType,
   cc_depth:: SubGoalDepth }

 I'm still in two minds about whether this is the best plan. Another
 possibility would be to have a predicate type for holes, somthing like
class Hole a where
  holeValue :: a

 It works the way it is, but there are some annoying special cases for
 CHoleCan (just grep for "CHoleCan").

  compiler/deSugar/Coverage.lhs  |1 +
  compiler/deSugar/DsExpr.lhs|2 +
  compiler/hsSyn/HsExpr.lhs  |3 +
  compiler/main/DynFlags.hs  |4 +-
  compiler/rename/RnExpr.lhs |   11 +-
  compiler/typecheck/Inst.lhs|   31 ++--
  compiler/typecheck/TcBinds.lhs |   90 
  compiler/typecheck/TcCanonical.lhs |9 +-
  compiler/typecheck/TcEnv.lhs   |   21 ++-
  compiler/typecheck/TcErrors.lhs|  443
 ++--
  compiler/typecheck/TcExpr.lhs  |9 +
  compiler/typecheck/TcHsSyn.lhs |3 +
  compiler/typecheck/TcMType.lhs |   14 +-
  compiler/typecheck/TcRnMonad.lhs   |   35 ++-
  compiler/typecheck/TcRnTypes.lhs   |   96 +---
  compiler/typecheck/TcRules.lhs |   28 ++-
  compiler/typecheck/TcSMonad.lhs|   36 ++--
  compiler/typecheck/TcSimplify.lhs  |  110 --
  compiler/typecheck/TcUnify.lhs |2 -
  compiler/types/Type.lhs|   18 +-
  20 files changed, 565 insertions(+), 401 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] #7278: nonsensical kind variable ascription causes panic

2012-10-02 Thread GHC

#7278: nonsensical kind variable ascription causes panic
+---
 Reporter:  nfrisby |  Owner: 
 Type:  bug | Status:  new
 Priority:  normal  |  Component:  Compiler (Type checker)
  Version:  7.6.1   |   Keywords: 
   Os:  Unknown/Multiple|   Architecture:  Unknown/Multiple   
  Failure:  Compile-time crash  |   Testcase: 
Blockedby:  |   Blocking: 
  Related:  |  
+---

Comment(by simonpj@…):

 commit 7fdc2a39d5c9a7d1be45b6314d480d16810a75ef
 {{{
 Author: Simon Peyton Jones 
 Date:   Sat Sep 29 13:37:02 2012 +0100

 Add missing case in TcUnify.matchExpectedFunKind

 This fixes Trac #7278

  compiler/typecheck/TcUnify.lhs |   27 +++
  1 files changed, 15 insertions(+), 12 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] #5030: Slow type checking of type-level computation heavy code.

2012-10-02 Thread GHC

#5030: Slow type checking of type-level computation heavy code.
---+
  Reporter:  thesz |  Owner: 
  Type:  bug   | Status:  new
  Priority:  normal|  Milestone:  7.2.1  
 Component:  Compiler (Type checker)   |Version:  7.0.2  
Resolution:|   Keywords: 
Os:  Unknown/Multiple  |   Architecture:  x86
   Failure:  Compile-time performance bug  | Difficulty:  Unknown
  Testcase:  T5030 |  Blockedby: 
  Blocking:|Related: 
---+

Comment(by simonpj@…):

 commit 902a8632c627304bc553557c21263c591ae63428
 {{{
 Author: Simon Peyton Jones 
 Date:   Tue Oct 2 09:20:53 2012 +0100

 Improve (and simplify) the short-circuiting of Refl coercions

 The constraint solver sometimes goes to a lot of effort that turns
 out to be Refl in the end, and avoiding zonking those proofs is a
 useful optimisation. (Trac #5030)

  compiler/typecheck/TcHsSyn.lhs |   45
 +++
  1 files changed, 17 insertions(+), 28 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] #7248: NewCodeGen does not create enough SRT labels when using SplitObjs

2012-10-02 Thread GHC

#7248: NewCodeGen does not create enough SRT labels when using SplitObjs
--+-
  Reporter:  darchon  |  Owner:  simonmar 
  Type:  bug  | Status:  closed   
  Priority:  highest  |  Milestone:  7.8.1
 Component:  Compiler (NCG)   |Version:  7.7  
Resolution:  fixed|   Keywords:  SplitObjs NCG SRT
Os:  MacOS X  |   Architecture:  x86  
   Failure:  Building GHC failed  | Difficulty:  Unknown  
  Testcase:   |  Blockedby:   
  Blocking:   |Related:   
--+-
Changes (by simonmar):

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


Comment:

 Great! thanks.

-- 
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] #7248: NewCodeGen does not create enough SRT labels when using SplitObjs

2012-10-02 Thread GHC

#7248: NewCodeGen does not create enough SRT labels when using SplitObjs
--+-
Reporter:  darchon|   Owner:  simonmar   
Type:  bug|  Status:  infoneeded 
Priority:  highest|   Milestone:  7.8.1  
   Component:  Compiler (NCG) | Version:  7.7
Keywords:  SplitObjs NCG SRT  |  Os:  MacOS X
Architecture:  x86| Failure:  Building GHC failed
  Difficulty:  Unknown|Testcase: 
   Blockedby: |Blocking: 
 Related: |  
--+-

Comment(by darchon):

 Everything is working using: 42cb30bd2c00705da598cc8d4170b41fb5693166

-- 
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] #7289: Mingw FPU init not Windows compatible.

2012-10-02 Thread GHC

#7289: Mingw FPU init not Windows compatible.
--+-
 Reporter:  Lennart   |  Owner:
 Type:  bug   | Status:  new   
 Priority:  normal|  Component:  Runtime System
  Version:  7.2.2 |   Keywords:
   Os:  Windows   |   Architecture:  x86   
  Failure:  None/Unknown  |   Testcase:
Blockedby:|   Blocking:
  Related:|  
--+-
 Mingw initializes the FPU top 80 bit precision instead of MSVC's 53 bits
 (which is the standard).  I suggest ghc linking on Windows should be
 changed to that it uses 53 bits instead.  This will make programs more
 Windows compatible (and possibly faster).

 Here's a comment from Mingw's Float.h:

 /*
 MSVCRT.dll _fpreset initializes the control register to 0x27f,
 the status register to zero and the tag word to 0h.
 This differs from asm instruction finit/fninit which set control
 word to 0x37f (64 bit mantissa precison rather than 53 bit).
 By default, the mingw version of _fpreset sets fp control as
 per fninit. To use the MSVCRT.dll _fpreset, include CRT_fp8.o when
 building your application.
 */

-- 
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] #7284: plusAddr# x 0 isn't optimised away

2012-10-02 Thread GHC

#7284: plusAddr# x 0 isn't optimised away
-+--
Reporter:  rl|   Owner:  igloo  
Type:  bug   |  Status:  new
Priority:  high  |   Milestone:  7.8.1  
   Component:  Compiler  | Version:  7.6.1  
Keywords:|  Os:  Unknown/Multiple   
Architecture:  Unknown/Multiple  | Failure:  Runtime performance bug
  Difficulty:  Unknown   |Testcase: 
   Blockedby:|Blocking: 
 Related:|  
-+--
Changes (by dterei):

 * cc: dterei (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] #7286: GHC doesn't optimise away primitive identity conversions

2012-10-02 Thread GHC

#7286: GHC doesn't optimise away primitive identity conversions
--+-
 Reporter:  rl|  Owner:  
 Type:  bug   | Status:  new 
 Priority:  normal|  Component:  Compiler
  Version:  7.7   |   Keywords:  
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
  Failure:  Compile-time performance bug  |   Testcase:  
Blockedby:|   Blocking:  
  Related:|  
--+-
Changes (by dterei):

 * cc: dterei (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

[GHC] #7288: type inference fails with where clause (RankNTypes, TypeFamilies)

2012-10-02 Thread GHC

#7288: type inference fails with where clause (RankNTypes, TypeFamilies)
---+
 Reporter:  agrafix|  Owner:
  
 Type:  bug| Status:  new   
  
 Priority:  normal |  Component:  Compiler (Type 
checker) 
  Version:  7.6.1  |   Keywords:  type inference, 
rankntypes, typefamilies
   Os:  Unknown/Multiple   |   Architecture:  Unknown/Multiple  
  
  Failure:  GHC rejects valid program  |   Testcase:
  
Blockedby: |   Blocking:
  
  Related: |  
---+
 when using RankNTypes and TypeFamilies with polymorphic functions, type
 inference works in let but not in where clauses.


 {{{
 {-# LANGUAGE RankNTypes #-}
 {-# LANGUAGE TypeFamilies #-}

 import Control.Monad

 class Monad m => GenM m where
 type GenReq m :: *

 type GenFun a b = forall m. GenM m => a -> m b
 data GenDef a b = GenDef { name :: String, fun :: GenFun a b }
 data Gen a b = Gen
 data Struct = Struct

 mkGen :: forall a b. String -> GenFun a b -> GenDef a b
 mkGen = GenDef

 runGen :: GenM m => Gen a b -> a -> m (Maybe b)
 runGen = undefined

 getPatients :: GenM m => m [Int]
 getPatients = undefined

 -- BROKEN
 myGen :: Gen String Struct -> GenDef Int [Struct]
 myGen structGen =
 mkGen "myGen" $ \pid ->
 do pats <- getPatients
structs <- mapM patToStruct pats
return structs
 where
   patToStruct pid =
   do Just struct <- runGen structGen (show pid)
  return struct

 -- WORKS
 myGen' :: Gen String Struct -> GenDef Int [Struct]
 myGen' structGen =
 mkGen "myGen" $ \pid ->
 do pats <- getPatients
let patToStruct pid =
do Just struct <- runGen structGen (show pid)
   return struct
structs <- mapM patToStruct pats
return structs

 -- WORKS
 myGen'' :: Gen String Struct -> GenDef Int [Struct]
 myGen'' structGen =
 mkGen "myGen" $ \pid ->
 do pats <- getPatients
structs <- mapM patToStruct pats
return structs
 where
   patToStruct :: GenM m => Int -> m Struct
   patToStruct pid =
   do Just struct <- runGen structGen (show pid)
  return struct

 }}}

-- 
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] #7283: Specialise INLINE functions

2012-10-02 Thread GHC

#7283: Specialise INLINE functions
-+--
Reporter:  rl|   Owner: 
Type:  feature request   |  Status:  new
Priority:  normal|   Milestone: 
   Component:  Compiler  | Version:  7.7
Keywords:|  Os:  Unknown/Multiple   
Architecture:  Unknown/Multiple  | Failure:  Runtime performance bug
  Difficulty:  Unknown   |Testcase: 
   Blockedby:|Blocking: 
 Related:|  
-+--

Comment(by rl):

 I'll try to rephrase the last paragraph. The problem is that this change
 will make GHC inline more since it will now be able (but not keen) to
 inline INLINE functions even if they aren't applied to enough arguments.
 The original reason for making INLINE respect arity was code bloat so we
 should be careful not to reintroduce this problem with this change.
 However, if INLINE functions that are not applied to enough arguments are
 treated exactly as INLINABLE then GHC won't try extra hard to inline them
 so perhaps we will be ok. This is different to what we had before the
 arity restriction on INLINE - back then, GHC would try extra hard to
 inline regardless of the number of arguments. So while we will inline more
 under my proposal, it will (hopefully) still be substantially less than in
 the bad old days.

-- 
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] #7248: NewCodeGen does not create enough SRT labels when using SplitObjs

2012-10-02 Thread GHC

#7248: NewCodeGen does not create enough SRT labels when using SplitObjs
--+-
Reporter:  darchon|   Owner:  simonmar   
Type:  bug|  Status:  infoneeded 
Priority:  highest|   Milestone:  7.8.1  
   Component:  Compiler (NCG) | Version:  7.7
Keywords:  SplitObjs NCG SRT  |  Os:  MacOS X
Architecture:  x86| Failure:  Building GHC failed
  Difficulty:  Unknown|Testcase: 
   Blockedby: |Blocking: 
 Related: |  
--+-
Changes (by simonmar):

  * status:  new => infoneeded


Comment:

 Could you try again now please?  I think I may have fixed 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

37 matches

Mail list logo