Re: [GHC] #2722: < when compiling with -O option with ghc-6.10.0.20081019

[GHC]

#2722: < when compiling with -O option with ghc-6.10.0.20081019
-+--
  Reporter:  uwe |  Owner:  simonpj   
  Type:  bug | Status:  infoneeded
  Priority:  normal  |  Milestone:  7.0.3 
 Component:  libraries (other)   |Version:  7.0.1 
Resolution:  |   Keywords:  arrows
  Testcase:  tyepcheck/should_run/T2722  |  Blockedby:
Difficulty:  Unknown | Os:  Linux 
  Blocking:  |   Architecture:  x86_64 (amd64)
   Failure:  Runtime crash   |  
-+--

Comment(by simonpj):

 Ah, yes, I recall this darcs-freezing thing happened to me to.  What fixed
 it was adding --no-cache, I think.  try that.

 As to your build error, you have done `./darcs-all get` haven't you?  I
 think you'd be better off with HEAD than with something from 10 Jan.

 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] #4894: Missing improvement for fun. deps.

[GHC]

#4894: Missing improvement for fun. deps.
+---
Reporter:  diatchki |Owner:  
Type:  feature request  |   Status:  new 
Priority:  normal   |Milestone:  _|_ 
   Component:  Compiler (Type checker)  |  Version:  7.1 
Keywords:   | Testcase:  
   Blockedby:   |   Difficulty:  
  Os:  Unknown/Multiple | Blocking:  
Architecture:  Unknown/Multiple |  Failure:  None/Unknown
+---
Changes (by simonpj):

  * type:  bug => feature request
  * milestone:  7.2.1 => _|_


Comment:

 Actually this is more of a feature request than a bug, and depends on some
 as-yet-undeveloped theory.

 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] #4945: Another SpecConstr infelicity

[GHC]

#4945: Another SpecConstr infelicity
-+--
Reporter:  batterseapower|Owner:
Type:  bug   |   Status:  merge 
Priority:  normal|Milestone:  7.0.2 
   Component:  Compiler  |  Version:  7.0.1 
Keywords:| Testcase:  simplCore/should_compile/T4945
   Blockedby:|   Difficulty:
  Os:  Unknown/Multiple  | Blocking:
Architecture:  Unknown/Multiple  |  Failure:  Runtime performance bug   
-+--
Changes (by simonpj):

  * testcase:  simplCore/should_compile/T4935 =>
   simplCore/should_compile/T4945


-- 
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] #4934: threadWaitRead works incorrectly on nonthreaded RTS

[GHC]

#4934: threadWaitRead works incorrectly on nonthreaded RTS
---+
Reporter:  slyfox  |Owner:  simonmar   
Type:  bug |   Status:  infoneeded 
Priority:  high|Milestone:  7.0.3  
   Component:  Runtime System  |  Version:  7.0.1  
Keywords:  | Testcase: 
   Blockedby:  |   Difficulty: 
  Os:  Linux   | Blocking: 
Architecture:  x86_64 (amd64)  |  Failure:  Incorrect result at runtime
---+
Changes (by simonmar):

 * cc: tibbe, bos (added)


Comment:

 This is the way it has always worked.  The problem is that when `select()`
 finds that one of the file descriptors has been closed, it returns an
 error, but doesn't tell you which one it was, so in that case we inform
 all the blocked threads that they should wake up, and retry whatever
 operation they were doing, which will result in the appropriate exception
 being thrown.  I presume that `epoll` is able to determine which file
 descriptor is erroneous and generate the exception from `threadWaitRead`
 instead.

 So typical uses of `threadWaitRead` won't notice the difference.  We could
 make the `epoll` backend ignore the exception, but that doesn't seem
 right.  Personally I'm happy to leave things as they are, but document
 that `threadWaitRead` may or may not raise an exception if the FD is
 closed (actually I'd like to remove `threadWaitRead` from
 `Control.Concurrent` anyway, it's really an internal API).

 tibbe/bos, any thoughts?

-- 
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] #4891: dataConInfoPtrToName doesn't correctly resolve constructors with a trailing .

[GHC]

#4891: dataConInfoPtrToName doesn't correctly resolve constructors with a 
trailing
.
-+--
Reporter:  TristanAllwood|Owner:  igloo   
Type:  bug   |   Status:  new 
Priority:  high  |Milestone:  7.0.3   
   Component:  Compiler  |  Version:  6.12.1  
Keywords:| Testcase:  
   Blockedby:|   Difficulty:  
  Os:  Unknown/Multiple  | Blocking:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--
Changes (by igloo):

  * owner:  => igloo


-- 
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] #4013: build fails on OS X: Invalid Mach-O file:Address out of bounds while relocating object file

[GHC]

#4013: build fails on OS X: Invalid Mach-O file:Address out of bounds while
relocating object file
-+--
Reporter:  igloo |Owner:  igloo  
Type:  bug   |   Status:  new
Priority:  high  |Milestone:  7.0.3  
   Component:  Compiler  |  Version:  6.13   
Keywords:| Testcase: 
   Blockedby:|   Difficulty: 
  Os:  MacOS X   | Blocking: 
Architecture:  x86   |  Failure:  Building GHC failed
-+--
Changes (by igloo):

  * owner:  => igloo


-- 
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] #4805: segfault in Data.HashTable, triggered by long Agda runs

[GHC]

#4805: segfault in Data.HashTable, triggered by long Agda runs
+---
Reporter:  wkahl|Owner:   
Type:  bug  |   Status:  infoneeded   
Priority:  normal   |Milestone:  7.0.3
   Component:  libraries/base   |  Version:  7.0.1
Keywords:  Data.HashTable segfault  | Testcase:   
   Blockedby:   |   Difficulty:   
  Os:  Linux| Blocking:   
Architecture:  x86_64 (amd64)   |  Failure:  Runtime crash
+---

Comment(by simonpj):

 Which version of GHC was this?  There was a bug in 6.12 which seg-faulted
 sometimes with very large heaps.  We can't make progress on this without
 more info.

 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

[GHC] #4957: Simplifier failes to eliminate redundant boxing/unboxing

[GHC]

#4957: Simplifier failes to eliminate redundant boxing/unboxing
-+--
Reporter:  simonpj   |Owner:  
Type:  bug   |   Status:  new 
Priority:  normal|Milestone:  
   Component:  Compiler  |  Version:  7.0.1   
Keywords:| Testcase:  
   Blockedby:|   Difficulty:  
  Os:  Unknown/Multiple  | Blocking:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--
 Consider this
 {{{
 f :: Bool -> Int -> Int
 f b 0 = 0
 f b x = let y = case b of
  True -> case f b (x-1) of
 I# v -> I# (v -# 1#)
  False -> case f b (x-1) of
 I# v -> I# (v +# 1#)
   in
   case b of
  True -> case y of
I# w -> I# (w -# 1#)

  False -> case y of
I# w -> I# (w +# 1#)
 }}}
 GHC 6.12 -O generates this:
 {{{
 T4941.$wf =
   \ (w_shC :: GHC.Bool.Bool) (ww_shF :: GHC.Prim.Int#) ->
 case ww_shF of ds_Xhm {
   __DEFAULT ->
 let {
   y_shQ :: GHC.Types.Int
   LclId
   [Str: DmdType m]
   y_shQ =
 case w_shC of _ {
   GHC.Bool.False ->
 case T4941.$wf GHC.Bool.False (GHC.Prim.-# ds_Xhm 1)
 of ww1_shJ { __DEFAULT ->
 GHC.Types.I# (GHC.Prim.+# ww1_shJ 1)
 };
   GHC.Bool.True ->
 case T4941.$wf GHC.Bool.True (GHC.Prim.-# ds_Xhm 1)
 of ww1_shJ { __DEFAULT ->
 GHC.Types.I# (GHC.Prim.-# ww1_shJ 1)
 }
 } } in
 case w_shC of _ {
   GHC.Bool.False ->
 case y_shQ of _ { GHC.Types.I# w1_adk -> GHC.Prim.+# w1_adk 1
 };
   GHC.Bool.True ->
 case y_shQ of _ { GHC.Types.I# w1_adj -> GHC.Prim.-# w1_adj 1
 }
 };
   0 -> 0
 }
 }}}
 Here y is used strictly, and boxes its value in every branch, and those
 uses immediately unbox it.  We'd prefer to generate an ''unboxed'' value
 for 'y'.

 This ticket is derived from #4941.

-- 
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] #4941: SpecConstr generates functions that do not use their arguments

[GHC]

#4941: SpecConstr generates functions that do not use their arguments
-+--
Reporter:  simonpj   |Owner: 
Type:  task  |   Status:  new
Priority:  normal|Milestone:  _|_
   Component:  Compiler  |  Version:  7.0.1  
Keywords:| Testcase: 
   Blockedby:|   Difficulty: 
  Os:  Unknown/Multiple  | Blocking: 
Architecture:  Unknown/Multiple  |  Failure:  Runtime performance bug
-+--

Comment(by simonpj):

 I've made a new ticket #4957 for the "excessive boxing" point, leaving
 this ticket to address its original purpose, namely the question of absent
 parameters.

 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] #4914: FPU initialization required again

[GHC]

#4914: FPU initialization required again
-+--
Reporter:  aruiz |Owner: 
Type:  bug   |   Status:  new
Priority:  normal|Milestone:  7.0.3  
   Component:  Compiler (NCG)|  Version:  7.0.1  
Keywords:| Testcase: 
   Blockedby:|   Difficulty: 
  Os:  Unknown/Multiple  | Blocking: 
Architecture:  x86   |  Failure:  Incorrect result at runtime
-+--

Comment(by aruiz):

 This problem seems to be exposed by some unpredictable combination of
 foreign calls and external libraries, so it is difficult to make a
 standalone testcase. I can try to prepare it, if it is acceptable that the
 testcase compiles several modules and links -lgsl -llapack.

 I'm sorry that it requires installation of packages, but could you
 reproduce the problem with the above method?

-- 
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] #4914: FPU initialization required again

[GHC]

#4914: FPU initialization required again
-+--
Reporter:  aruiz |Owner: 
Type:  bug   |   Status:  new
Priority:  normal|Milestone:  7.0.3  
   Component:  Compiler (NCG)|  Version:  7.0.1  
Keywords:| Testcase: 
   Blockedby:|   Difficulty: 
  Os:  Unknown/Multiple  | Blocking: 
Architecture:  x86   |  Failure:  Incorrect result at runtime
-+--

Comment(by simonmar):

 In the patch

 {{{
 Implement SSE2 floating-point support in the x86 native code generator
 (#594)
 }}}

 I "optimised" the x87 backend to avoid some of the `ffree`s that seemed
 unnecessary.  It's entirely possible that I got this wrong (but I just
 took a quick look and did't see any obvious problems).

 What we ought to do is make a small C function that will fail if the x87
 stack is non-empty, and have the RTS call it at shutdown time.  Then
 running the testsuite should find a smaller failure case.  I'm a little
 busy to do this right now, but if anyone else wants to have a go please go
 ahead.

-- 
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] #4451: Re-linking avoidance is too aggressive

[GHC]

#4451: Re-linking avoidance is too aggressive
-+--
Reporter:  simonmar  |Owner:
Type:  bug   |   Status:  new   
Priority:  high  |Milestone:  7.2.1 
   Component:  Compiler  |  Version:  7.1   
Keywords:| Testcase:
   Blockedby:|   Difficulty:  Moderate (less than a day)
  Os:  Unknown/Multiple  | Blocking:
Architecture:  Unknown/Multiple  |  Failure:  Other 
-+--
Changes (by simonmar):

  * priority:  normal => high


Comment:

 I'm getting more annoyed by the lack of this, so bumping priority.

-- 
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] #4805: segfault in Data.HashTable, triggered by long Agda runs

[GHC]

#4805: segfault in Data.HashTable, triggered by long Agda runs
+---
Reporter:  wkahl|Owner:   
Type:  bug  |   Status:  infoneeded   
Priority:  normal   |Milestone:  7.0.3
   Component:  libraries/base   |  Version:  7.0.1
Keywords:  Data.HashTable segfault  | Testcase:   
   Blockedby:   |   Difficulty:   
  Os:  Linux| Blocking:   
Architecture:  x86_64 (amd64)   |  Failure:  Runtime crash
+---

Comment(by wkahl):

 This should have been 7.0.1 - I'll try to reproduce this after Feb. 21.

-- 
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] #4953: panic: urk! lookup local fingerprint main:B.throwErr{v rR3}

[GHC]

#4953: panic: urk! lookup local fingerprint main:B.throwErr{v rR3}
-+--
Reporter:  igloo |Owner:  igloo   
Type:  bug   |   Status:  new 
Priority:  highest   |Milestone:  7.0.2   
   Component:  Compiler  |  Version:  7.0.1   
Keywords:| Testcase:  
   Blockedby:|   Difficulty:  
  Os:  Unknown/Multiple  | Blocking:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--
Changes (by simonpj):

  * owner:  => igloo


Comment:

 Well characterised!  This should fix it:
 {{{
 Mon Feb 14 14:03:34 GMT 2011  simo...@microsoft.com
   * Fix Trac #4953: local let binders can have IdInfo with free names

   Local let binders in IfaceExpr never used to have unfoldings,
   but lately they can (becuase they can have an INLINE pragma).
   We must take account of the variables mentioned in the pragma
   when computing the fingerprint.
 }}}
 Can you test and then close?

 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] #4934: threadWaitRead works incorrectly on nonthreaded RTS

[GHC]

#4934: threadWaitRead works incorrectly on nonthreaded RTS
---+
Reporter:  slyfox  |Owner:  simonmar   
Type:  bug |   Status:  infoneeded 
Priority:  high|Milestone:  7.0.3  
   Component:  Runtime System  |  Version:  7.0.1  
Keywords:  | Testcase: 
   Blockedby:  |   Difficulty: 
  Os:  Linux   | Blocking: 
Architecture:  x86_64 (amd64)  |  Failure:  Incorrect result at runtime
---+

Comment(by tibbe):

 Replying to [comment:9 simonmar]:
 > So typical uses of `threadWaitRead` won't notice the difference.  We
 could make the `epoll` backend ignore the exception, but that doesn't seem
 right.  Personally I'm happy to leave things as they are, but document
 that `threadWaitRead` may or may not raise an exception if the FD is
 closed (actually I'd like to remove `threadWaitRead` from
 `Control.Concurrent` anyway, it's really an internal API).
 >
 > tibbe/bos, any thoughts?

 I agree. I think `threadWaitRead` should raise an exception for closed
 FDs. Otherwise it might mask programmer bugs.

-- 
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] #4867: ghci displays negative floats incorrectly (was: Incorrect result from trig functions)

[GHC]

#4867: ghci displays negative floats incorrectly (was: Incorrect result from 
trig
functions)
---+
Reporter:  gwright |Owner:  gwright
Type:  bug |   Status:  new
Priority:  high|Milestone:  7.0.2  
   Component:  GHCi|  Version:  7.0.1  
Keywords:  | Testcase: 
   Blockedby:  |   Difficulty: 
  Os:  MacOS X | Blocking: 
Architecture:  x86_64 (amd64)  |  Failure:  Incorrect result at runtime
---+

Comment(by gwright):

 The answer to the misalignment is even simpler than I thought.  For
 relocations that aren't external or through the global offset table, the
 displacement is the code should be left unchanged.  I've corrected my
 change to `rts/Linker.c` to do this.

 These null fixups are a bit odd, but I guess they are they take care of
 some corner case.

 I've run the entire testsuite with my new patch and get 70 unexpected
 failures, 12 of which are `ghci` failures.  I this is better than before,
 but not dramatically so.

 The reason that we're not seeing an impressive reduction in test failures
 is that the bad relocations were quite uncommon: only 50 relocations were
 non-external/non-GOT out of the approximately 21 performed when `ghci`
 starts with with no files specified on the command line.

 Once the updated patch is applied, it's probably time to close this bug.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

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

Re: [GHC] #4934: threadWaitRead works incorrectly on nonthreaded RTS

[GHC]

#4934: threadWaitRead works incorrectly on nonthreaded RTS
---+
Reporter:  slyfox  |Owner:  simonmar   
Type:  bug |   Status:  infoneeded 
Priority:  high|Milestone:  7.0.3  
   Component:  Runtime System  |  Version:  7.0.1  
Keywords:  | Testcase: 
   Blockedby:  |   Difficulty: 
  Os:  Linux   | Blocking: 
Architecture:  x86_64 (amd64)  |  Failure:  Incorrect result at runtime
---+

Comment(by simonmar):

 The problem is that we can't easily make `threadWaitRead` raise an
 exception for closed FDs in the non-threaded RTS where we use `select`,
 because we have no information about which FD has the error.  Presumably
 the same applies in the new IO manager when using `poll`?

-- 
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] #4958: Ambiguous module name `Prelude' (base haskell98-1.1.0.0)

[GHC]

#4958: Ambiguous module name `Prelude' (base haskell98-1.1.0.0)
---+
Reporter:  EvgenijM86  |   Owner: 
Type:  bug |  Status:  new
Priority:  normal  |   Component:  Prelude
 Version:  7.1 |Keywords:  haskell-src Prelude
Testcase:  |   Blockedby: 
  Os:  Linux   |Blocking: 
Architecture:  x86_64 (amd64)  | Failure:  None/Unknown   
---+
 I was trying to compile haskell-src-1.0.1.4 with ghc-7.1.20110213 and got
 this error message:

 {{{
 evgenij@evgenij-dsk:~$ cabal install --reinstall --with-
 compiler=/home/evgenij/ghc-7.1.20110213/bin/ghc haskell-src-1.0.1.4
 Resolving dependencies...
 Configuring haskell-src-1.0.1.4...
 Preprocessing library haskell-src-1.0.1.4...
 shift/reduce conflicts:  2
 Building haskell-src-1.0.1.4...

 Implicit import declaration:
 Ambiguous module name `Prelude':
   it was found in multiple packages: base haskell98-1.1.0.0
 cabal: Error: some packages failed to install:
 haskell-src-1.0.1.4 failed during the building phase. The exception was:
 ExitFailure 1
 }}}

 I don't know if this is specific to ghc-7.1.20110213 or some other 7.x.x
 versions are affected (it did compile on 6.12.3 though). Adding --ghc-
 option="-hide-package haskell98-1.1.0.0" seems to have no effect.

-- 
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] #4959: Warning about variables with leading underscore that are used anyway

[GHC]

#4959: Warning about variables with leading underscore that are used anyway
-+--
Reporter:  Lemming   |   Owner: 
   
Type:  feature request   |  Status:  new
   
Priority:  normal|   Component:  Compiler (Parser)  
   
 Version:  7.0.1 |Keywords:  warning unused underscore 
variable
Testcase:|   Blockedby: 
   
  Os:  Unknown/Multiple  |Blocking: 
   
Architecture:  Unknown/Multiple  | Failure:  None/Unknown   
   
-+--
 I use -Wall all the time, which includes -fwarn-unused-binds and -fwarn-
 unused-matches that warn about variable bindings that are not used. It
 already spotted lots of mistakes for me. You can suppress the warning by
 prepending an underscore '_' to a variable name. However, I have recently
 seen code, where variable names with leading underscores are regularly
 used, where other programmers might have chosen trailing underscores or
 primes. I suspect that the programmer was not aware, that he disabled
 warnings about unused bindings this way. Thus I like to have a warning
 about underscored variables that are used in the sense of the definition
 given for -fwarn-unused-binds in
 http://www.haskell.org/ghc/docs/latest/html/users_guide/options-
 sanity.html.
 We still have to decide whether this warning should be part of -Wall or
 -fwarn-unused-binds or whether there should be a separate option like
 -fwarn-used-underscored-binds.

-- 
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] #4934: threadWaitRead works incorrectly on nonthreaded RTS

[GHC]

#4934: threadWaitRead works incorrectly on nonthreaded RTS
---+
Reporter:  slyfox  |Owner:  simonmar   
Type:  bug |   Status:  infoneeded 
Priority:  high|Milestone:  7.0.3  
   Component:  Runtime System  |  Version:  7.0.1  
Keywords:  | Testcase: 
   Blockedby:  |   Difficulty: 
  Os:  Linux   | Blocking: 
Architecture:  x86_64 (amd64)  |  Failure:  Incorrect result at runtime
---+

Comment(by tibbe):

 Replying to [comment:11 simonmar]:
 > The problem is that we can't easily make `threadWaitRead` raise an
 exception for closed FDs in the non-threaded RTS where we use `select`,
 because we have no information about which FD has the error.  Presumably
 the same applies in the new IO manager when using `poll`?

 `poll` sets `POLLNVAL` per FD so that should be possible.

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