date:20121025

Re: [GHC] #7353: Make system IO interruptible on Windows

2012-10-25 Thread GHC

#7353: Make system IO interruptible on Windows
-+--
Reporter:  joeyadams |   Owner: 
Type:  bug   |  Status:  new
Priority:  normal|   Milestone:  7.8.1  
   Component:  libraries/base| Version:  7.6.1  
Keywords:|  Os:  Windows
Architecture:  Unknown/Multiple  | Failure:  Incorrect result at runtime
  Difficulty:  Unknown   |Testcase: 
   Blockedby:|Blocking: 
 Related:|  
-+--

Comment(by joeyadams):

 Good point.  Indeed,
 [http://hackage.haskell.org/packages/archive/base/latest/doc/html/System-
 IO.html#v:hWaitForInput hWaitForInput] uses a blocking FFI call even on
 Unix.  I think we should still provide a way to wait for sockets on
 Windows that actually works, but that can be a separate ticket.

 Thanks for pointing that out.  IOCP it is.

 I should elaborate more on the thread sensitivity issue.  Based on what
 I've read, overlapped IO is canceled on [http://msdn.microsoft.com/en-
 us/library/ms682659.aspx thread exit].  Moreover, to cancel pending IO
 ourselves, we need to call [http://msdn.microsoft.com/en-
 us/library/windows/desktop/aa363791%28v=vs.85%29.aspx CancelIo] from the
 same OS thread that initiated the IO, to avoid canceling unrelated IO.
 The latter restriction can be avoided by using [http://msdn.microsoft.com
 /en-us/library/windows/desktop/aa363792%28v=vs.85%29.aspx CancelIoEx], but
 it requires Windows Vista or later.

 Therefore, we enforce this rule: for each OS thread, no more than one
 pending IO request per HANDLE.  Thus, one thread may serve a large number
 of HANDLEs, but multiple concurrent requests on the same HANDLE will
 require separate threads.

 The IO manager would provide the following wrapper:

 {{{
 -- | Do something that supports overlapped I/O, and wait for it to
 complete.
 withIOCP :: HANDLE-- ^ Device to operate on.  Must be
 associated
   --   with the IO manager using
 'registerHandle'.
  -> (Ptr OVERLAPPED -> IO ()) -- ^ Callback which starts the IO
  -> IO Completion

 -- | Associate a device handle with the IO manager's completion port.
 -- It will be unassociated automatically when the handle is closed.
 registerHandle :: HANDLE -> IO ()
 }}}

 It does the following sequence:

  - Allocate and zero an [http://msdn.microsoft.com/en-
 us/library/ms684342%28v=vs.85%29.aspx OVERLAPPED] structure, paired with
 an MVar wrapped in a !StablePtr used for signaling completion.

  - Acquire an OS thread that isn't waiting for a completion on the same
 HANDLE.  Both the callback and !CancelIo need to be called from the same
 OS thread, and this thread must not go away until we're done.

  - Run the callback, passing it the new OVERLAPPED structure.  On
 exception, free our OVERLAPPED and !StablePtr.

  Note that if the IO completes immediately
 ([http://stackoverflow.com/questions/985/what-happens-with-win32-io-
 completion-port-and-synchronous-appearing-io which can happen]), the
 completion port will still receive a completion.  Possible optimization:
 skip waiting for the IO manager and read the OVERLAPPED structure right
 away; I don't know if this is safe, though.

  - Wait for the IO manager to fill our MVar.  On exception, issue
 !CancelIo.  We do not need to unregister the OVERLAPPED or free it, since
 !CancelIo will cause a completion to be delivered, meaning we can free it
 from the IO manager.

  - Return the completion (either an error code, or the number of bytes
 transferred).

 So how do we do the "acquire an OS thread" step?  Well, one way would be
 to manage a thread pool using
 [http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-
 Concurrent.html#v:forkOS forkOS], and pass IO jobs to it.  But that means
 handing every IO job off to an OS thread.

 Suppose Control.Concurrent had a wrapper that lets us simply use the
 current thread, then use that same thread later on.  The problem is, what
 if the current OS thread, after starting IO for one green thread, makes a
 blocking FFI call for another green thread?  We'd have to wait for that to
 complete before doing our !CancelIo.

 I think the hand-off is unavoidable, unless:

  * The caller is already running a bound thread.

  * [http://msdn.microsoft.com/en-
 us/library/windows/desktop/aa363792%28v=vs.85%29.aspx CancelIoEx] is
 available.  This can be tested at run-time, as I
 [https://github.com/joeyadams/haskell-system-time-
 monotonic/blob/master/cbits/dll.c did for GetTickCount64] in my
 [http://hackage.haskell.org/package/system-time-

Re: [GHC] #7347: Existential data constructors should not be promoted

2012-10-25 Thread GHC

#7347: Existential data constructors should not be promoted
-+--
Reporter:  simonpj   |   Owner:  
Type:  bug   |  Status:  new 
Priority:  normal|   Milestone:  
   Component:  Compiler  | Version:  7.6.1   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--

Comment(by simonpj):

 Well this
 {{{
 type instance MkEx x = x
 }}}
 should give an existential escape error, but it doesn't. Instead it
 somehow fixes the kind to *.

 You are arguing for this in general.  If we promote a data constructor,
 such as `Just`, whose type is
 {{{
  Just :: forall a. a -> Maybe a
 }}}
 then we get poly-kinded type constructor
 {{{
  'Just :: forlal k. k -> 'Maybe k
 }}}
 You are arguing for some different type-promotion rule for existentials.
 Maybe, but I have never thought about that and I don't know what the
 details would be.

 If you want something that isn't kind-polymorphic, you don't need an
 existential at all. Wha you want is something like
 {{{
 data kind Ex = MkEx *
 }}}
 a perfectly ordinary non-existential data type with an argument of kind
 `*`.  Now, as Pedro points out in his ICFP paper we don't have a way to
 say that, but that is quite a separate matter; existntials are a total red
 herring.  Maybe we should have
 {{{
 data Ex = MkEx STAR
 }}}
 where `STAR` is an uninhabited type whose promotion to the kind level is
 `*`.

-- 
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] #7367: Optimiser / Linker Problem on amd64

2012-10-25 Thread GHC

#7367: Optimiser / Linker Problem on amd64
-+--
 Reporter:  wurmli   |  Owner:
 Type:  bug  | Status:  new   
 Priority:  normal   |  Component:  Build System  
  Version:  7.6.1|   Keywords:
   Os:  Linux|   Architecture:  x86_64 (amd64)
  Failure:  Runtime performance bug  |   Testcase:
Blockedby:   |   Blocking:
  Related:   |  
-+--
 The Haskell fannkuchredux contribution of Louis Wasserman to "The Computer
 Language Benchmarks Game" at shootout.alioth.debian.org times out on the
 amd64 machines, but not on the i386. I can reproduce it on my Debian amd64
 machine.

 It turns out that compiling without optimisation or with a simple -O
 produces a fast program, but with enourmously large heap space allocated
 (10G compared with 67k on a virtual i386 machine) and also more garbage
 collector activity.

 The source is below (because I don't find a way to attach the file). At
 the end  of the source I copied my make command line, run command line and
 output produced with option -sstderr.

 -


 {{{
 {-  The Computer Language Benchmarks Game
 http://shootout.alioth.debian.org/
 contributed by Louis Wasserman

 This should be compiled with:
 -threaded -O2 -fexcess-precision -fasm
 and run with:
 +RTS -N -RTS 
 -}

 import Control.Concurrent
 import Control.Monad
 import System.Environment
 import Foreign hiding (rotate)
 import Data.Monoid

 type Perm = Ptr Word8

 data F = F {-# UNPACK #-} !Int {-# UNPACK #-} !Int

 instance Monoid F where
 mempty = F 0 0
 F s1 m1 `mappend` F s2 m2 = F (s1 + s2) (max m1 m2)

 incPtr = (`advancePtr` 1)
 decPtr = (`advancePtr` (-1))

 flop :: Int -> Perm -> IO ()
 flop k xs = flopp xs (xs `advancePtr` k)
  where flopp i j = when (i < j) $ swap i j >> flopp (incPtr i) (decPtr j)
swap i j = do
 a <- peek i
 b <- peek j
 poke j a
 poke i b

 flopS :: Perm -> (Int -> IO a) -> IO a
 flopS !xs f = do
 let go !acc = do
 k <- peekElemOff xs 0
 if k == 0 then f acc else flop (fromIntegral k) xs >> go
 (acc+1)
 go 0

 increment :: Ptr Word8 -> Ptr Word8 -> IO ()
 increment !p !ct = do
 first <- peekElemOff p 1
 pokeElemOff p 1 =<< peekElemOff p 0
 pokeElemOff p 0 first

 let go !i !first = do
 ci <- peekElemOff ct i
 if fromIntegral ci < i then pokeElemOff ct i (ci+1) else
 do
 pokeElemOff ct i 0
 let !i' = i + 1
 moveArray p (incPtr p) i'
 pokeElemOff p i' first
 go i' =<< peekElemOff p 0
 go 1 first

 genPermutations :: Int -> Int -> Int -> Ptr Word8 -> Ptr Word8 -> IO F
 genPermutations !n !l !r !perm !count = allocaArray n $ \ destF -> do
 let upd j !f run = do
 p0 <- peekElemOff perm 0
 if p0 == 0 then increment perm count >> run f else do
 copyArray destF perm n
 increment perm count
 flopS destF $ \ flops ->
 run (f `mappend` F (checksum j flops)
 flops)
 let go j !f = if j >= r then return f else upd j f (go (j+1))
 go l mempty
  where checksum i f = if i .&. 1 == 0 then f else -f

 facts :: [Int]
 facts = scanl (*) 1 [1..12]

 unrank :: Int -> Int -> (Ptr Word8 -> Ptr Word8 -> IO a) -> IO a
 unrank !idx !n f = allocaArray n $ \ p -> allocaArray n $ \ count ->
   allocaArray n $ \ pp -> do
 mapM_ (\ i -> pokeElemOff p i (fromIntegral i)) [0..n-1]
 let go i !idx = when (i >= 0) $ do
 let fi = facts !! i
 let (q, r) = idx `quotRem` fi
 pokeElemOff count i (fromIntegral q)
 copyArray pp p (i+1)
 let go' j = when (j <= i) $ do
 let jq = j + q
 pokeElemOff p j =<< peekElemOff pp (if jq <= i
 then jq else jq - i - 1)
 go' (j+1)
 go' 0
 go (i-1) r
 go (n-1) idx
 f p count

 main = do
n <- fmap (read.head) getArgs
let fact = product [1..n]
let bk = fact `quot` 4
vars <- forM [0,bk..fact-1] $ \ ix -> do
 var <- newEmptyMVar
 forkIO (unrank ix n $ \ p -> genPermutations n ix (min fact (ix +
 bk)) p >=> putMVar var)
 return var
F chksm mflops <- liftM mconcat (mapM takeMVar vars)
putStrLn $ (show chksm) ++ "\nPfannkuchen(" ++ (show n) ++ ") =

Re: [GHC] #7318: CONLIKE pragma documentation bug

2012-10-25 Thread GHC

#7318: CONLIKE pragma documentation bug
-+--
Reporter:  acowley   |   Owner:  igloo
Type:  bug   |  Status:  merge
Priority:  normal|   Milestone:  7.6.2
   Component:  Documentation | Version:  7.6.1
Keywords:|  Os:  Unknown/Multiple 
Architecture:  Unknown/Multiple  | Failure:  Documentation bug
  Difficulty:  Unknown   |Testcase:   
   Blockedby:|Blocking:   
 Related:|  
-+--
Changes (by igloo):

  * status:  new => merge


Comment:

 Thanks for the report; fixed.

-- 
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] #7347: Existential data constructors should not be promoted

2012-10-25 Thread GHC

#7347: Existential data constructors should not be promoted
-+--
Reporter:  simonpj   |   Owner:  
Type:  bug   |  Status:  new 
Priority:  normal|   Milestone:  
   Component:  Compiler  | Version:  7.6.1   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--

Comment(by kosmikus):

 Well, this works in 7.6.1:

 {{{
 data Ex = forall a. MkEx a

 type family F (t :: Ex) :: *
 type instance F (MkEx Int)  = Int
 type instance F (MkEx Bool) = String
 }}}

 And I don't see how it's dangerous or any different from this:

 {{{
 data Wrap = MkWrap Int

 f :: Wrap -> Int
 f (MkWrap 0) = 0
 f (MkWrap 1) = 42
 }}}

 The point is still that if the kind of the promoted constructor is
 {{{
 MkEx :: * -> Ex
 }}}
 then there's no actual existential on the type level. We've just created a
 wrapper for values of kind *. I'm ''not'' arguing that we should promote
 constructors that would get polymorphic kinds of the form
 {{{
 MkStrange :: forall k. k -> Ex
 }}}

 AFAIK, Pedro makes use of promoted existentials in at least one of his
 generic universe encodings. So it'd be nice if they keep working, unless
 there's actually a problem with them.

-- 
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] #7318: CONLIKE pragma documentation bug

2012-10-25 Thread GHC

#7318: CONLIKE pragma documentation bug
-+--
Reporter:  acowley   |   Owner:  igloo
Type:  bug   |  Status:  new  
Priority:  normal|   Milestone:  7.6.2
   Component:  Documentation | Version:  7.6.1
Keywords:|  Os:  Unknown/Multiple 
Architecture:  Unknown/Multiple  | Failure:  Documentation bug
  Difficulty:  Unknown   |Testcase:   
   Blockedby:|Blocking:   
 Related:|  
-+--

Comment(by ian@…):

 commit e0c77c9f0729c105dddc5ce3fc79e117951719ba
 {{{
 Author: Ian Lynagh 
 Date:   Thu Oct 25 20:54:41 2012 +0100

 Fix doc typo; fixes #7318

  docs/users_guide/glasgow_exts.xml |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] #7347: Existential data constructors should not be promoted

2012-10-25 Thread GHC

#7347: Existential data constructors should not be promoted
-+--
Reporter:  simonpj   |   Owner:  
Type:  bug   |  Status:  new 
Priority:  normal|   Milestone:  
   Component:  Compiler  | Version:  7.6.1   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--

Comment(by simonpj):

 As far as I know, we don't currently have a mechanism for pattern matching
 on an existential data constructor at the type level.  I'm pretty sure
 that 7.6.1 is broken in this respect.

-- 
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] #7338: Duplicate type signature not reported

2012-10-25 Thread GHC

#7338: Duplicate type signature not reported
+---
Reporter:  evincarofautumn  |   Owner:  michalt
Type:  bug  |  Status:  patch  
Priority:  normal   |   Milestone: 
   Component:  Compiler | Version:  7.4.1  
Keywords:   |  Os:  Unknown/Multiple   
Architecture:  x86  | Failure:  GHC accepts invalid program
  Difficulty:  Unknown  |Testcase: 
   Blockedby:   |Blocking: 
 Related:  #5589|  
+---
Changes (by simonpj):

  * difficulty:  => Unknown


Comment:

 Thank you for the patch. As it happens I've already fixed this but been so
 swamped that I have not pushed the change. Sorry about that.  I'll do so
 shortly.  And I'll add your example as an extra test, thank you.

 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] #7338: Duplicate type signature not reported

2012-10-25 Thread GHC

#7338: Duplicate type signature not reported
-+--
 Reporter:  evincarofautumn  |  Owner:  michalt 
 Type:  bug  | Status:  patch   
 Priority:  normal   |  Component:  Compiler
  Version:  7.4.1|   Keywords:  
   Os:  Unknown/Multiple |   Architecture:  x86 
  Failure:  GHC accepts invalid program  |   Testcase:  
Blockedby:   |   Blocking:  
  Related:  #5589|  
-+--
Changes (by michalt):

  * status:  new => patch
  * os:  MacOS X => Unknown/Multiple
  * related:  http://hackage.haskell.org/trac/ghc/ticket/5589 => #5589


Comment:

 When looking at this ticket I've noticed another problem with the current
 approach.
 The following code
 {{{
 module Test where

 a, b :: Int
 a = undefined
 b = undefined

 c, a :: Int
 c = undefined

 c, d :: Int
 d = undefined
 }}}
 would generate only one warning (this is due to using "overlapping" with
 ```findDupsEq```).
 The attached patch reworks the way we check for duplicates. AFAICS all
 problematic cases should be handled correctly and we get a slightly better
 error messages too (the patch for the testsuite has examples).

 Let me know if you think that in some cases the output is not as expected.

-- 
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] #7357: GHC.exe gives an internal error while linking vector's Monadic.hs

2012-10-25 Thread GHC

#7357: GHC.exe gives an internal error while linking vector's Monadic.hs
---+
Reporter:  kapilash|   Owner:
Type:  bug |  Status:  new   
Priority:  normal  |   Milestone:  7.8.1 
   Component:  GHCi| Version:  7.6.1 
Keywords:  |  Os:  Windows   
Architecture:  x86_64 (amd64)  | Failure:  Compile-time crash
  Difficulty:  Unknown |Testcase:
   Blockedby:  3658|Blocking:
 Related:  |  
---+
Changes (by igloo):

  * owner:  igloo =>
  * component:  Compiler => GHCi
  * blockedby:  => 3658


Comment:

 I can't reproduce this for some reason.

 Nevertheless, it would be fixed by #3658.

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

2012-10-25 Thread GHC

#7292: Optimization works for Word but not Word32 or Word64
--+-
  Reporter:  zuserm   |  Owner:  igloo   
  Type:  bug  | Status:  closed  
  Priority:  high |  Milestone:  7.8.1   
 Component:  Compiler |Version:  7.6.1   
Resolution:  fixed|   Keywords:  
Os:  Unknown/Multiple |   Architecture:  Unknown/Multiple
   Failure:  Runtime performance bug  | Difficulty:  Unknown 
  Testcase:   |  Blockedby:  
  Blocking:   |Related:  
--+-
Changes (by igloo):

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


Comment:

 Thanks for the report. Fixed by:
 {{{
 commit 6fae60c48d13b4c3d8cbb3bf317b1af95d162924
 Author: Ian Lynagh 
 Date:   Thu Oct 25 17:13:36 2012 +0100

 Make sure testBit and bit get inlined; fixes #7292
 }}}

-- 
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] #5401: LANGUAGE pragma parser nit

2012-10-25 Thread GHC

#5401: LANGUAGE pragma parser nit
--+-
Reporter:  nwf|   Owner:  igloo
Type:  bug|  Status:  new  
Priority:  normal |   Milestone:  7.6.2
   Component:  Compiler (Parser)  | Version:  7.0.3
Keywords: |  Os:  Linux
Architecture:  x86_64 (amd64) | Failure:  GHC rejects valid program
  Difficulty:  Unknown|Testcase:   
   Blockedby: |Blocking:   
 Related: |  
--+-
Changes (by igloo):

  * difficulty:  => Unknown


Old description:

> A language pragma like
>
> {-# LANGUAGE
> TypeOperators,
> FlexibleContexts #-}
>
> parses just fine but
>
> {-# LANGUAGE
> TypeOperators,
> FlexibleContexts
> #-}
>
> doesn't, saying:
>
> Cannot parse LANGUAGE pragma
> Expecting comma-separated list of language options,
> each starting with a capital letter
>
> An OPTIONS pragma, on the other hand, accepts either format without
> complaint.

New description:

 A language pragma like
 {{{
 {-# LANGUAGE
 TypeOperators,
 FlexibleContexts #-}
 }}}
 parses just fine but
 {{{
 {-# LANGUAGE
 TypeOperators,
 FlexibleContexts
 #-}
 }}}
 doesn't, saying:
 {{{
 Cannot parse LANGUAGE pragma
 Expecting comma-separated list of language options,
 each starting with a capital letter
 }}}
 An OPTIONS pragma, on the other hand, accepts either format without
 complaint.

--

-- 
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] #3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-} pragmas/extensions

2012-10-25 Thread GHC

#3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-}
pragmas/extensions
+---
  Reporter:  eflister   |  Owner:  igloo
   
  Type:  feature request| Status:  new  
   
  Priority:  normal |  Milestone:  7.8.1
   
 Component:  Compiler (Parser)  |Version:  6.10.4   
   
Resolution: |   Keywords:  language pragma extensions 
error message warning
Os:  Unknown/Multiple   |   Architecture:  Unknown/Multiple 
   
   Failure:  None/Unknown   | Difficulty:  Unknown  
   
  Testcase: |  Blockedby:   
   
  Blocking: |Related:   
   
+---
Changes (by igloo):

  * milestone:  7.6.2 => 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] #3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-} pragmas/extensions

2012-10-25 Thread GHC

#3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-}
pragmas/extensions
+---
  Reporter:  eflister   |  Owner:  igloo
   
  Type:  feature request| Status:  new  
   
  Priority:  normal |  Milestone:  7.6.2
   
 Component:  Compiler (Parser)  |Version:  6.10.4   
   
Resolution: |   Keywords:  language pragma extensions 
error message warning
Os:  Unknown/Multiple   |   Architecture:  Unknown/Multiple 
   
   Failure:  None/Unknown   | Difficulty:  Unknown  
   
  Testcase: |  Blockedby:   
   
  Blocking: |Related:   
   
+---
Changes (by igloo):

  * difficulty:  => Unknown


Comment:

 The main problem I find with "-XFoo" is that you can't easily select it
 just by double clicking on it. That means that if you want to put it into
 a LANGUAGE pragma then you have to manually select everything apart from
 the X.

 What do people think about allowing "-X Foo" as a command-line flag, and
 then using that form in error messages?

-- 
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] #7233: Int64 division buggy on a 32-bit installation

2012-10-25 Thread GHC

#7233: Int64 division buggy on a 32-bit installation
-+--
Reporter:  lerkok|   Owner:
Type:  bug   |  Status:  merge 
Priority:  highest   |   Milestone:  7.6.2 
   Component:  libraries/base| Version:  7.6.1 
Keywords:|  Os:  Unknown/Multiple  
Architecture:  Unknown/Multiple  | Failure:  None/Unknown  
  Difficulty:  Unknown   |Testcase:  tests/numeric/should_run/T7233
   Blockedby:|Blocking:
 Related:|  
-+--
Changes (by simonmar):

  * status:  new => merge
  * testcase:  => tests/numeric/should_run/T7233


-- 
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] #7233: Int64 division buggy on a 32-bit installation

2012-10-25 Thread GHC

#7233: Int64 division buggy on a 32-bit installation
-+--
Reporter:  lerkok|   Owner:  
Type:  bug   |  Status:  new 
Priority:  highest   |   Milestone:  7.6.2   
   Component:  libraries/base| Version:  7.6.1   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--

Comment(by simonmar):

 Fixed, test still to come:

 {{{
 commit 4137f8c1259e02dc1992c9d6771f45f495e7cef4
 Author: Simon Marlow 
 Date:   Wed Oct 24 16:57:39 2012 +0100

 Fix #7233: avoid overflow in divInt64#
 }}}

-- 
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] #7359: unix-2.6.0.0 fails to install on mac os x with 7.4.* (works with 7.6.1) (was: unix-2.6.0.0 fails to install on mac os x)

2012-10-25 Thread GHC

#7359: unix-2.6.0.0 fails to install on mac os x with 7.4.* (works with 7.6.1)
+---
 Reporter:  AndreasVoellmy  |  Owner:
 Type:  bug | Status:  new   
 Priority:  normal  |  Component:  libraries/unix
  Version:  7.4.1   |   Keywords:
   Os:  MacOS X |   Architecture:  x86_64 (amd64)
  Failure:  Other   |   Testcase:
Blockedby:  |   Blocking:
  Related:  |  
+---

Comment(by jfischoff):

 I am also getting this, but the really odd thing about it is I only get it
 with GHC 7.4.2, works fine with 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] #7366: Strange data corruption with HEAD

2012-10-25 Thread GHC

#7366: Strange data corruption with HEAD
--+-
  Reporter:  bgamari  |  Owner:  
  Type:  bug  | Status:  closed  
  Priority:  normal   |  Milestone:  7.8.1   
 Component:  Compiler |Version:  7.7 
Resolution:  fixed|   Keywords:  
Os:  Unknown/Multiple |   Architecture:  Unknown/Multiple
   Failure:  Building GHC failed  | Difficulty:  Unknown 
  Testcase:   |  Blockedby:  
  Blocking:   |Related:  
--+-
Changes (by simonmar):

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


Comment:

 Now fixed, I believe.

-- 
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] #7366: Strange data corruption with HEAD

2012-10-25 Thread GHC

#7366: Strange data corruption with HEAD
--+-
  Reporter:  bgamari  |  Owner:  
  Type:  bug  | Status:  new 
  Priority:  normal   |  Milestone:  7.8.1   
 Component:  Compiler |Version:  7.7 
Resolution:   |   Keywords:  
Os:  Unknown/Multiple |   Architecture:  Unknown/Multiple
   Failure:  Building GHC failed  | Difficulty:  Unknown 
  Testcase:   |  Blockedby:  
  Blocking:   |Related:  
--+-

Comment(by marlowsd@…):

 commit c588395719241c4b5756bd8d60dbf822915dfc5b
 {{{
 Author: Simon Marlow 
 Date:   Thu Oct 25 16:18:36 2012 +0100

 Fix a bug in CmmSink exposed by a recent optimisation (#7366)

  compiler/cmm/CmmSink.hs |   10 ++
  1 files changed, 10 insertions(+), 0 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] #7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf

2012-10-25 Thread GHC

#7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf
-+--
Reporter:  bgamari   |   Owner:  
Type:  bug   |  Status:  new 
Priority:  highest   |   Milestone:  7.8.1   
   Component:  Compiler  | Version:  7.7 
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  Runtime crash   
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--
Changes (by simonmar):

  * priority:  normal => highest
  * difficulty:  => Unknown
  * version:  => 7.7
  * 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] #7366: Strange data corruption with HEAD

2012-10-25 Thread GHC

#7366: Strange data corruption with HEAD
--+-
  Reporter:  bgamari  |  Owner:  
  Type:  bug  | Status:  new 
  Priority:  normal   |  Milestone:  7.8.1   
 Component:  Compiler |Version:  7.7 
Resolution:   |   Keywords:  
Os:  Unknown/Multiple |   Architecture:  Unknown/Multiple
   Failure:  Building GHC failed  | Difficulty:  Unknown 
  Testcase:   |  Blockedby:  
  Blocking:   |Related:  
--+-
Changes (by simonmar):

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


Comment:

 I do have a repro in one of my builds, but the patch didn't fix it.  Re-
 opening.

-- 
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] #7366: Strange data corruption with HEAD

2012-10-25 Thread GHC

#7366: Strange data corruption with HEAD
--+-
  Reporter:  bgamari  |  Owner:  simonmar
  Type:  bug  | Status:  closed  
  Priority:  normal   |  Milestone:  7.8.1   
 Component:  Compiler |Version:  7.7 
Resolution:  fixed|   Keywords:  
Os:  Unknown/Multiple |   Architecture:  Unknown/Multiple
   Failure:  Building GHC failed  | Difficulty:  Unknown 
  Testcase:   |  Blockedby:  
  Blocking:   |Related:  
--+-

Comment(by bgamari):

 Thanks! I'm doing a test build right now.

 Both machines I was able to reproduce on are x86_64 running some variant
 of Linux (one running a 2.6.31 kernel, the other 3.7).

-- 
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] #7347: Existential data constructors should not be promoted

2012-10-25 Thread GHC

#7347: Existential data constructors should not be promoted
-+--
Reporter:  simonpj   |   Owner:  
Type:  bug   |  Status:  new 
Priority:  normal|   Milestone:  
   Component:  Compiler  | Version:  7.6.1   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--

Comment(by kosmikus):

 It seems that all that GHC 7.6.1 currently allows is to promote
 existentially quantified variables of kind *. Such constructors, if
 promoted, lead to simply kinded datatypes. No polymorphism, no
 existentials on that level. So why not keep allowing them? There's no
 danger of escaping variables even for type families, afaics.

 The bug Stefan reports seems to be a missing check whether the type is
 used according to its inferred kind.

-- 
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] #7319: +RTS -xc sometimes results in segfault

2012-10-25 Thread GHC

#7319: +RTS -xc sometimes results in segfault
-+--
Reporter:  edsko |   Owner:  
Type:  bug   |  Status:  merge   
Priority:  high  |   Milestone:  7.6.2   
   Component:  Runtime System| Version:  7.6.1   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--
Changes (by simonmar):

  * status:  new => merge


Comment:

 I think the above commit should fix it.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

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

Re: [GHC] #7351: showRichTokenStream has an off-by one error on starting col

2012-10-25 Thread GHC

#7351: showRichTokenStream has an off-by one error on starting col
-+--
Reporter:  alanz |   Owner:  simonmar
Type:  bug   |  Status:  merge   
Priority:  normal|   Milestone:  7.6.2   
   Component:  GHC API   | Version:  7.6.1   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--
Changes (by simonmar):

  * status:  new => merge


-- 
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] #7319: +RTS -xc sometimes results in segfault

2012-10-25 Thread GHC

#7319: +RTS -xc sometimes results in segfault
-+--
Reporter:  edsko |   Owner:  
Type:  bug   |  Status:  new 
Priority:  high  |   Milestone:  7.6.2   
   Component:  Runtime System| Version:  7.6.1   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--

Comment(by marlowsd@…):

 commit 467e1a623d405440021e92572638be22f0cf5dda
 {{{
 Author: Simon Marlow 
 Date:   Wed Oct 24 13:39:34 2012 +0100

 fprintCCS_stderr: untag the exception (#7319)

  rts/Profiling.c |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] #7351: showRichTokenStream has an off-by one error on starting col

2012-10-25 Thread GHC

#7351: showRichTokenStream has an off-by one error on starting col
-+--
Reporter:  alanz |   Owner:  simonmar
Type:  bug   |  Status:  new 
Priority:  normal|   Milestone:  7.6.2   
   Component:  GHC API   | Version:  7.6.1   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--

Comment(by marlowsd@…):

 commit cdf1389865885c190d4b2f0eb81fc659b375fb6f
 {{{
 Author: Simon Marlow 
 Date:   Wed Oct 24 13:23:08 2012 +0100

 fix off-by-one-column in showRichTokenStream (#7351)

  compiler/main/GHC.hs |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] #7350: 'stg_killMyself' undeclared (first use in this function)

2012-10-25 Thread GHC

#7350: 'stg_killMyself' undeclared (first use in this function)
--+-
  Reporter:  erikd|  Owner:  
  Type:  bug  | Status:  closed  
  Priority:  normal   |  Milestone:  
 Component:  Compiler |Version:  7.7 
Resolution:  fixed|   Keywords:  
Os:  Unknown/Multiple |   Architecture:  Unknown/Multiple
   Failure:  Building GHC failed  | Difficulty:  Unknown 
  Testcase:   |  Blockedby:  
  Blocking:   |Related:  
--+-
Changes (by simonmar):

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


Comment:

 @erikd - you're seeing these failures because the PPC64 build compiles via
 C, and the C backend is more sensitive than the other backends to
 declaration order.  I've committed what should be a fix for the issues you
 saw, but I suspect there may still be other problems in the unregisterised
 backend.  Please re-open or open new tickets as appropriate.

-- 
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] #7366: Strange data corruption with HEAD

2012-10-25 Thread GHC

#7366: Strange data corruption with HEAD
--+-
  Reporter:  bgamari  |  Owner:  simonmar
  Type:  bug  | Status:  closed  
  Priority:  normal   |  Milestone:  7.8.1   
 Component:  Compiler |Version:  7.7 
Resolution:  fixed|   Keywords:  
Os:  Unknown/Multiple |   Architecture:  Unknown/Multiple
   Failure:  Building GHC failed  | Difficulty:  Unknown 
  Testcase:   |  Blockedby:  
  Blocking:   |Related:  
--+-
Changes (by simonmar):

  * status:  new => closed
  * version:  => 7.7
  * resolution:  => fixed
  * milestone:  => 7.8.1


Comment:

 So I haven't yet been able to reproduce the bug, but I think I know what
 it is so I've committed a speculative fix.  I'll optimistically close the
 bug, please re-open if it still occurs.

-- 
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] #7366: Strange data corruption with HEAD

2012-10-25 Thread GHC

#7366: Strange data corruption with HEAD
-+--
Reporter:  bgamari   |   Owner:  simonmar   
Type:  bug   |  Status:  new
Priority:  normal|   Milestone: 
   Component:  Compiler  | Version: 
Keywords:|  Os:  Unknown/Multiple   
Architecture:  Unknown/Multiple  | Failure:  Building GHC failed
  Difficulty:  Unknown   |Testcase: 
   Blockedby:|Blocking: 
 Related:|  
-+--

Comment(by marlowsd@…):

 commit 24b4bfbcb320670a62dad10009d43f06211a5a2a
 {{{
 Author: Simon Marlow 
 Date:   Thu Oct 25 09:25:49 2012 +0100

 Fix bug in 88a6f863d9f127fc1b03a1e2f068fd20ecbe096c (#7366)

  compiler/cmm/CmmSink.hs |   40 
  1 files changed, 20 insertions(+), 20 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] #7350: 'stg_killMyself' undeclared (first use in this function)

2012-10-25 Thread GHC

#7350: 'stg_killMyself' undeclared (first use in this function)
-+--
 Reporter:  erikd|  Owner:  
 Type:  bug  | Status:  new 
 Priority:  normal   |  Component:  Compiler
  Version:  7.7  |   Keywords:  
   Os:  Unknown/Multiple |   Architecture:  Unknown/Multiple
  Failure:  Building GHC failed  |   Testcase:  
Blockedby:   |   Blocking:  
  Related:   |  
-+--

Comment(by marlowsd@…):

 commit 9008ae051311066e46a088b899fa6b908d292a70
 {{{
 Author: Simon Marlow 
 Date:   Thu Oct 25 09:43:34 2012 +0100

 declare stg_gc_prim and stg_killMyself (#7350)

  includes/stg/MiscClosures.h |2 ++
  1 files changed, 2 insertions(+), 0 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] #7366: Strange data corruption with HEAD

2012-10-25 Thread GHC

#7366: Strange data corruption with HEAD
-+--
Reporter:  bgamari   |   Owner:  simonmar   
Type:  bug   |  Status:  new
Priority:  normal|   Milestone: 
   Component:  Compiler  | Version: 
Keywords:|  Os:  Unknown/Multiple   
Architecture:  Unknown/Multiple  | Failure:  Building GHC failed
  Difficulty:  Unknown   |Testcase: 
   Blockedby:|Blocking: 
 Related:|  
-+--
Changes (by simonmar):

  * difficulty:  => Unknown


Comment:

 What platform and build 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

Re: [GHC] #7353: Make system IO interruptible on Windows

2012-10-25 Thread GHC

#7353: Make system IO interruptible on Windows
-+--
Reporter:  joeyadams |   Owner: 
Type:  bug   |  Status:  new
Priority:  normal|   Milestone:  7.8.1  
   Component:  libraries/base| Version:  7.6.1  
Keywords:|  Os:  Windows
Architecture:  Unknown/Multiple  | Failure:  Incorrect result at runtime
  Difficulty:  Unknown   |Testcase: 
   Blockedby:|Blocking: 
 Related:|  
-+--

Comment(by simonmar):

 I'm not an expert on Windows async I/O and I haven't read all the
 documentation thoroughly, so please take my opinions with a pinch of salt.

 I'm personally not concerned about being able to implement
 `threadWaitRead`: I think of that as an internal API used to implement
 blocking I/O.  We only have it because this API happens to work with
 select()/epoll().  If the underlying OS interfaces don't map well to
 `threadWaitRead`, then we should redesign the API at that level, rather
 than going to a lot of trouble to emulate `threadWaitRead`.

 It looks like your plan would work, but I wonder whether we ought to go to
 IOCP instead.  Regarding the two points you make about IOCP:

  * no way to wait for readiness: as I said, I don't think we need
 `threadWaitRead`, and `IODevice.ready` can be implemented another way (we
 already have `fdReady` for this)

  * This is slightly annoying.  One solution is to make the I/O manager a
 bound thread, and hand off all I/O operations to that thread, then we just
 ensure that this thread never exits.  Or if the hand-off to a bound thread
 is too expensive, we will need a separate mechanism to prevent worker
 threads that have outstanding I/O requests from being terminated - a
 simple refcounting scheme will probably work fine here.

-- 
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] #7353: Make system IO interruptible on Windows

Re: [GHC] #7347: Existential data constructors should not be promoted

[GHC] #7367: Optimiser / Linker Problem on amd64

Re: [GHC] #7318: CONLIKE pragma documentation bug

Re: [GHC] #7347: Existential data constructors should not be promoted

Re: [GHC] #7318: CONLIKE pragma documentation bug

Re: [GHC] #7347: Existential data constructors should not be promoted

Re: [GHC] #7338: Duplicate type signature not reported

Re: [GHC] #7338: Duplicate type signature not reported

Re: [GHC] #7357: GHC.exe gives an internal error while linking vector's Monadic.hs

Re: [GHC] #7292: Optimization works for Word but not Word32 or Word64

Re: [GHC] #5401: LANGUAGE pragma parser nit

Re: [GHC] #3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-} pragmas/extensions

Re: [GHC] #3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-} pragmas/extensions

Re: [GHC] #7233: Int64 division buggy on a 32-bit installation

Re: [GHC] #7233: Int64 division buggy on a 32-bit installation

Re: [GHC] #7359: unix-2.6.0.0 fails to install on mac os x with 7.4.* (works with 7.6.1) (was: unix-2.6.0.0 fails to install on mac os x)

Re: [GHC] #7366: Strange data corruption with HEAD

Re: [GHC] #7366: Strange data corruption with HEAD

Re: [GHC] #7361: Segmentation fault on 5f37e0c71ff4af8539c5aebc739b006b4f0c6ebf

Re: [GHC] #7366: Strange data corruption with HEAD

Re: [GHC] #7366: Strange data corruption with HEAD

Re: [GHC] #7347: Existential data constructors should not be promoted

Re: [GHC] #7319: +RTS -xc sometimes results in segfault

Re: [GHC] #7351: showRichTokenStream has an off-by one error on starting col

Re: [GHC] #7319: +RTS -xc sometimes results in segfault

Re: [GHC] #7351: showRichTokenStream has an off-by one error on starting col

Re: [GHC] #7350: 'stg_killMyself' undeclared (first use in this function)

Re: [GHC] #7366: Strange data corruption with HEAD

Re: [GHC] #7366: Strange data corruption with HEAD

Re: [GHC] #7350: 'stg_killMyself' undeclared (first use in this function)

Re: [GHC] #7366: Strange data corruption with HEAD

Re: [GHC] #7353: Make system IO interruptible on Windows

33 matches

Site Navigation

Mail list logo

Footer information