date:20120117

Re: [GHC] #367: Infinite loops can hang Concurrent Haskell

2012-01-17 Thread GHC

#367: Infinite loops can hang Concurrent Haskell
--+-
  Reporter:  simonpj  |  Owner: 
 
  Type:  bug  | Status:  new
 
  Priority:  lowest   |  Milestone:  _|_
 
 Component:  Compiler |Version:  6.4.1  
 
Resolution:  None |   Keywords:  scheduler 
allocation
Os:  Unknown/Multiple |   Architecture:  Unknown/Multiple   
 
   Failure:  Incorrect result at runtime  | Difficulty:  Unknown
 
  Testcase:   |  Blockedby: 
 
  Blocking:   |Related: 
 
--+-
Changes (by lpsmith):

 * cc: leon.p.smith@… (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] #5784: Forked thread running infinite loop blocks other threads from running

2012-01-17 Thread GHC

#5784: Forked thread running infinite loop blocks other threads from running
-+--
 Reporter:  joeyadams|  Owner:
 Type:  bug  | Status:  new   
 Priority:  normal   |  Component:  Runtime System
  Version:  7.2.2|   Keywords:
   Os:  Linux|   Architecture:  x86_64 (amd64)
  Failure:  Incorrect result at runtime  |   Testcase:
Blockedby:   |   Blocking:
  Related:   |  
-+--

Comment(by lpsmith):

 Probably related:  #367

-- 
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] #5784: Forked thread running infinite loop blocks other threads from running

2012-01-17 Thread GHC

#5784: Forked thread running infinite loop blocks other threads from running
-+--
 Reporter:  joeyadams|  Owner:
 Type:  bug  | Status:  new   
 Priority:  normal   |  Component:  Runtime System
  Version:  7.2.2|   Keywords:
   Os:  Linux|   Architecture:  x86_64 (amd64)
  Failure:  Incorrect result at runtime  |   Testcase:
Blockedby:   |   Blocking:
  Related:   |  
-+--
Changes (by kmcallister):

 * cc: mcallister.keegan@… (added)


Comment:

 Note that the `main` thread is a `forkOS`-style bound thread:

 {{{
 $ cat foo.hs
 import Control.Concurrent
 main = isCurrentThreadBound >>= print

 $ ghc -threaded foo.hs && ./foo
 [1 of 1] Compiling Main ( foo.hs, foo.o )
 Linking foo ...
 True
 }}}

 In your example, if I rename `main` to `main'` and set

 {{{
 main = forkIO main' >> forever (threadDelay maxBound)
 }}}

 then I do see the `"Forked "` message.

 Perhaps the non-allocating loop is monopolizing the specific OS thread
 where `main` is bound.

-- 
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] #5784: Forked thread running infinite loop blocks other threads from running

2012-01-17 Thread GHC

#5784: Forked thread running infinite loop blocks other threads from running
-+--
 Reporter:  joeyadams|  Owner:
 Type:  bug  | Status:  new   
 Priority:  normal   |  Component:  Runtime System
  Version:  7.2.2|   Keywords:
   Os:  Linux|   Architecture:  x86_64 (amd64)
  Failure:  Incorrect result at runtime  |   Testcase:
Blockedby:   |   Blocking:
  Related:   |  
-+--

Comment(by lpsmith):

 This actually makes sense to me;  if 7.2.2 is smarter about
 reducing/eliminating memory allocation than 7.0.3,  then you could
 eliminate all your yield points.

 What doesn't make quite sense to me,  is why this fails to work even
 -threaded -N2.   Are Haskell threads tied to a particular capability?   Or
 at least,  if a Haskell thread never yields,  would the Haskell threads on
 that capability be stuck?

-- 
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] #5796: Runtime caught in an infinite loop

2012-01-17 Thread GHC

#5796: Runtime caught in an infinite loop
---+
Reporter:  lpsmith |Owner:
Type:  bug |   Status:  closed
Priority:  normal  |Component:  Runtime System
 Version:  7.4.1-rc1   |   Resolution:  duplicate 
Keywords:  |   Os:  Linux 
Architecture:  x86_64 (amd64)  |  Failure:  Runtime crash 
Testcase:  |Blockedby:
Blocking:  |  Related:
---+
Changes (by lpsmith):

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


Comment:

 Yes, I do believe it is a combination of the bugs above.

-- 
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] #5783: Data.Text.isPrefixOf fails to terminate

2012-01-17 Thread GHC

#5783: Data.Text.isPrefixOf fails to terminate
-+--
 Reporter:  reinerp  |  Owner:
 Type:  bug  | Status:  new   
 Priority:  normal   |  Component:  Compiler  
  Version:  7.4.1-rc1|   Keywords:
   Os:  MacOS X  |   Architecture:  x86_64 (amd64)
  Failure:  Incorrect result at runtime  |   Testcase:
Blockedby:   |   Blocking:
  Related:   |  
-+--
Changes (by lpsmith):

 * cc: leon.p.smith@… (added)


Comment:

 I can confirm this on ghc-7.4.0.2012011 on 64-bit Ubuntu 11.10.   Also see
 #5796.

-- 
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] #5784: Forked thread running infinite loop blocks other threads from running

2012-01-17 Thread GHC

#5784: Forked thread running infinite loop blocks other threads from running
-+--
 Reporter:  joeyadams|  Owner:
 Type:  bug  | Status:  new   
 Priority:  normal   |  Component:  Runtime System
  Version:  7.2.2|   Keywords:
   Os:  Linux|   Architecture:  x86_64 (amd64)
  Failure:  Incorrect result at runtime  |   Testcase:
Blockedby:   |   Blocking:
  Related:   |  
-+--

Comment(by lpsmith):

 Also see #5796,  which is probably 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] #5784: Forked thread running infinite loop blocks other threads from running

2012-01-17 Thread GHC

#5784: Forked thread running infinite loop blocks other threads from running
-+--
 Reporter:  joeyadams|  Owner:
 Type:  bug  | Status:  new   
 Priority:  normal   |  Component:  Runtime System
  Version:  7.2.2|   Keywords:
   Os:  Linux|   Architecture:  x86_64 (amd64)
  Failure:  Incorrect result at runtime  |   Testcase:
Blockedby:   |   Blocking:
  Related:   |  
-+--
Changes (by lpsmith):

 * cc: leon.p.smith@… (added)


Comment:

 I can confirm this with ghc-7.4.0.20120111 on Ubuntu 11.10 amd64.

-- 
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] #5796: Runtime caught in an infinite loop

2012-01-17 Thread GHC

#5796: Runtime caught in an infinite loop
---+
 Reporter:  lpsmith|  Owner:
 Type:  bug| Status:  new   
 Priority:  normal |  Component:  Runtime System
  Version:  7.4.1-rc1  |   Keywords:
   Os:  Linux  |   Architecture:  x86_64 (amd64)
  Failure:  Runtime crash  |   Testcase:
Blockedby: |   Blocking:
  Related: |  
---+

Comment(by lpsmith):

 This bug may be a confluence of #5784 and #5783.

-- 
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] #5796: Runtime caught in an infinite loop

2012-01-17 Thread GHC

#5796: Runtime caught in an infinite loop
---+
 Reporter:  lpsmith|  Owner:
 Type:  bug| Status:  new   
 Priority:  normal |  Component:  Runtime System
  Version:  7.4.1-rc1  |   Keywords:
   Os:  Linux  |   Architecture:  x86_64 (amd64)
  Failure:  Runtime crash  |   Testcase:
Blockedby: |   Blocking:
  Related: |  
---+

Comment(by lpsmith):

 Ok, I think I have a better fix on what is going on now;  I finally
 managed to replicate the bug in a program I specifically wrote to trigger
 this bug,  instead of one I cut down from the actual program I am writing.

 If I get some time tomorrow,  I'll see if I can't study the code path
 triggered inside of configurator and develop an example that doesn't
 depend directly on it.   But I think I can rule out a library bug,  as it
 works fine on GHC 7.0.3 with the same libraries and an infinite
 nonproductive loop outside of an unsafe FFI call shouldn't block the other
 Haskell threads.

-- 
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] #5788: Missing document about RTS's -T option

2012-01-17 Thread GHC

#5788: Missing document about RTS's -T option
-+--
Reporter:  shelarcy  |Owner:  ezyang   
Type:  bug   |   Status:  closed   
Priority:  normal|Component:  Documentation
 Version:  7.4.1-rc1 |   Resolution:  fixed
Keywords:|   Os:  Unknown/Multiple 
Architecture:  Unknown/Multiple  |  Failure:  Documentation bug
Testcase:|Blockedby:   
Blocking:|  Related:   
-+--
Changes (by ezyang):

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


Comment:

 {{{
 commit 3e63df8732b3e8556c32c060a114e997c990ccd7
 Author: Edward Z. Yang 
 Date:   Tue Jan 17 23:55:53 2012 -0500

 Document -T RTS flag in manual.

 Signed-off-by: Edward Z. Yang 

 }}}

-- 
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] #5796: Runtime caught in an infinite loop

2012-01-17 Thread GHC

#5796: Runtime caught in an infinite loop
---+
 Reporter:  lpsmith|  Owner:
 Type:  bug| Status:  new   
 Priority:  normal |  Component:  Runtime System
  Version:  7.4.1-rc1  |   Keywords:
   Os:  Linux  |   Architecture:  x86_64 (amd64)
  Failure:  Runtime crash  |   Testcase:
Blockedby: |   Blocking:
  Related: |  
---+
 Triggering this bug seems a little fragile;  but the program and method
 I've attached triggers the bug every time for me.   It is minimal-ish, I
 certainly have cut it down a lot,  and it perhaps could be made even
 smaller,  but a lot of seemingly irrelevant changes to the file will fail
 to trigger the bug.

 {{{
 $ cabal configure && cabal build
 $ ./dist/build/deadlock/deadlock
 }}}

 And then edit the file and change the 1 to some other value,  like 2.
 Configurator will reload the file within a second,  and then I see that
 the thread that periodically writes something to standard out stops
 working,  and that CPU usage goes to 100%,  and that I can no longer type
 something in and have the program echo it back to me.

 GHC-7.0.3 has no problem running this program.

-- 
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] #5795: Breaking the staging restriction in type splices causes GHC panic

2012-01-17 Thread GHC

#5795: Breaking the staging restriction in type splices causes GHC panic
--+-
 Reporter:  reinerp   |  Owner:  
 Type:  bug   | Status:  new 
 Priority:  normal|  Component:  Template Haskell
  Version:  7.4.1-rc1 |   Keywords:  
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
  Failure:  None/Unknown  |   Testcase:  
Blockedby:|   Blocking:  
  Related:|  
--+-
 Test case:
 {{{
 {-# LANGUAGE TemplateHaskell #-}
 module B where

 import Language.Haskell.TH

 ty :: Q Type
 ty = [t| Int |]

 f :: $ty
 f = undefined
 }}}

 The error message is:

 {{{

 B.hs:9:6:
 GHC internal error: `ty' is not in scope during type checking, but it
 passed the renamer
 tcl_env of environment: []
 In the expression: ty
 In the type signature for `f': f :: $ty
 }}}

 This is the same error as in #5792.

-- 
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] #5793: make fibon not suck

2012-01-17 Thread GHC

#5793: make fibon not suck
--+-
 Reporter:  dterei|  Owner:  dterei   
 Type:  task  | Status:  new  
 Priority:  normal|  Component:  NoFib benchmark suite
  Version:|   Keywords:   
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple 
  Failure:  None/Unknown  |   Testcase:   
Blockedby:|   Blocking:  5794 
  Related:|  
--+-

Comment(by dterei):

 Pushed a whole bunch of fixes so that fibon all compiles now at least. Now
 need to do some work on framework and make sure all the tests have
 significant run-times.

-- 
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] #5785: Test failures on i386 with LLVM backend

2012-01-17 Thread GHC

#5785: Test failures on i386 with LLVM backend
-+--
 Reporter:  dterei   |  Owner:  dterei  
 Type:  bug  | Status:  merge   
 Priority:  normal   |  Component:  Compiler (LLVM) 
  Version:  7.4.1-rc1|   Keywords:  
   Os:  Unknown/Multiple |   Architecture:  Unknown/Multiple
  Failure:  Incorrect result at runtime  |   Testcase:  
Blockedby:   |   Blocking:  
  Related:  #5757|  
-+--

Comment(by dterei):

 Ian please merge into 7.4.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] #5785: Test failures on i386 with LLVM backend

2012-01-17 Thread GHC

#5785: Test failures on i386 with LLVM backend
-+--
 Reporter:  dterei   |  Owner:  dterei  
 Type:  bug  | Status:  merge   
 Priority:  normal   |  Component:  Compiler (LLVM) 
  Version:  7.4.1-rc1|   Keywords:  
   Os:  Unknown/Multiple |   Architecture:  Unknown/Multiple
  Failure:  Incorrect result at runtime  |   Testcase:  
Blockedby:   |   Blocking:  
  Related:  #5757|  
-+--
Changes (by dterei):

  * status:  new => merge


Comment:

 Fixed in e86a7c7c75df3377ce961dc240f75abc845847bf.

 Bug was truncating int64 / word64 literals from 64bit to 32bit on i386
 before printing them out.

-- 
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] #5794: Fibon nightly regressions with pretty graphs

2012-01-17 Thread GHC

#5794: Fibon nightly regressions with pretty graphs
--+-
 Reporter:  dterei|  Owner:  dterei   
 Type:  task  | Status:  new  
 Priority:  normal|  Component:  NoFib benchmark suite
  Version:|   Keywords:   
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple 
  Failure:  None/Unknown  |   Testcase:   
Blockedby:  5793  |   Blocking:   
  Related:|  
--+-
 It would be great to have fibon run nightly and display pretty graphs and
 detect regressions.

 This depends on fixing up fibon first.

-- 
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] #5793: make fibon not suck

2012-01-17 Thread GHC

#5793: make fibon not suck
--+-
 Reporter:  dterei|  Owner:  dterei   
 Type:  task  | Status:  new  
 Priority:  normal|  Component:  NoFib benchmark suite
  Version:|   Keywords:   
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple 
  Failure:  None/Unknown  |   Testcase:   
Blockedby:|   Blocking:   
  Related:|  
--+-

Comment(by tibbe):

 I assume you mean nofib, not fibon.

-- 
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] #5793: make fibon not suck

2012-01-17 Thread GHC

#5793: make fibon not suck
--+-
 Reporter:  dterei|  Owner:  dterei   
 Type:  task  | Status:  new  
 Priority:  normal|  Component:  NoFib benchmark suite
  Version:|   Keywords:   
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple 
  Failure:  None/Unknown  |   Testcase:   
Blockedby:|   Blocking:   
  Related:|  
--+-
 fibon is the standard tool GHC developers use to benchmark changes to the
 compiler. Its a known fact though that fibon sucks. Its overall design is
 OK but it's had no love and care for many years and has bittrotted into
 near uselessness in a lot of situations.

 This task isn't to implement an awesome, really useful benchmark suite for
 Haskell. That would be great but is a huge undertaking. This task is just
 about making fibon useful again.

 The breakdown for this is something like:

 1. Think and maybe fix fibon framework design. It has 'ways' which I think
 correspond to compilation method but more in the sense of 'dynamic' vs
 'static', seems it may not suite being able to use ways for 'fasm' vs
 'fllvm'. There is also the concept of 'modes' which corresponds to
 different benchmark input. So 'normal' and 'slow' for getting different
 run-times. At moment no easy way to select which benchmark groups to run,
 so may want to change that. I guess we should just decide, what knobs do
 we want to be able to easily tweak, and see how well the current design
 allows that.

 2. Fixup the runtimes for benchmarks to be significant. (A lot of them run
 in < 1 or < 0.1 seconds). I think trying to get all of them to run in
 around 10s is a good target.

 3. Above task is to fix normal but we may want to fixup slow as well and
 perhaps add a 'fast' mode where benchmarks run in around 1 second.

 4. Maybe add more benchmarks to the suite (text, bytestring, performance
 regressions from ghc testsuite, vector)

-- 
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] #888: Implement the static argument transformation

2012-01-17 Thread GHC

#888: Implement the static argument transformation
-+--
Reporter:  simonpj   |   Owner:  
Type:  task  |  Status:  new 
Priority:  low   |   Milestone:  7.4.1   
   Component:  Compiler  | Version:  6.4.2   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  N/A 
   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] #1371: Add -O3

2012-01-17 Thread GHC

#1371: Add  -O3
---+
Reporter:  simonmar|   Owner:  
Type:  task|  Status:  new 
Priority:  normal  |   Milestone:  _|_ 
   Component:  Compiler| Version:  6.6.1   
Keywords:  |  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple| Failure:  None/Unknown
  Difficulty:  Moderate (less than a day)  |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] #1371: Add -O3

2012-01-17 Thread GHC

#1371: Add  -O3
---+
Reporter:  simonmar|   Owner:  
Type:  task|  Status:  new 
Priority:  normal  |   Milestone:  _|_ 
   Component:  Compiler| Version:  6.6.1   
Keywords:  |  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple| Failure:  None/Unknown
  Difficulty:  Moderate (less than a day)  |Testcase:  
   Blockedby:  |Blocking:  
 Related:  |  
---+
Changes (by dterei):

  * failure:  => None/Unknown


Comment:

 This would also be relevant for the LLVM backend. I haven't enabled every
 bell and whistle at -O2 so as to keep compile speeds down. -O3 would be
 nice to be a little more 'experimental' in its aggressiveness.

-- 
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] #5792: PolyKinds and recompilation causes internal error

2012-01-17 Thread GHC

#5792: PolyKinds and recompilation causes internal error
+---
 Reporter:  reinerp |  Owner: 
 Type:  bug | Status:  new
 Priority:  normal  |  Component:  Compiler (Type checker)
  Version:  7.4.1-rc1   |   Keywords: 
   Os:  MacOS X |   Architecture:  Unknown/Multiple   
  Failure:  Compile-time crash  |   Testcase: 
Blockedby:  |   Blocking: 
  Related:  |  
+---
 Given these two files:
 {{{
 module A where
 -- empty
 }}}

 and

 {{{

 {-# LANGUAGE PolyKinds, TypeFamilies, UndecidableInstances #-}
 module B where

 import A

 data T = TT

 type family Compare (m :: T) :: Ordering
 type instance Compare TT = Compare TT

 type Compare' a = Compare a
 }}}

 We can cause an internal GHC error as follows:

 {{{
 $ rm *.o *.hi
 $ ghc B.hs
 [1 of 2] Compiling A( A.hs, A.o )
 [2 of 2] Compiling B( B.hs, B.o )
 $ sleep 1
 $ touch B.hs
 $ ghc B.hs
 [2 of 2] Compiling B( B.hs, B.o )

 B.hs:11:19:
 GHC internal error: `Compare' is not in scope during type checking,
 but it passed the renamer
 tcl_env of environment: [(a9R, AThing k_a9U)]
 In the type `Compare a'
 In the type synonym declaration for Compare'
 }}}

-- 
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] #5788: Missing document about RTS's -T option

2012-01-17 Thread GHC

#5788: Missing document about RTS's -T option
---+
 Reporter:  shelarcy   |  Owner:  ezyang  
 Type:  bug| Status:  new 
 Priority:  normal |  Component:  Documentation   
  Version:  7.4.1-rc1  |   Keywords:  
   Os:  Unknown/Multiple   |   Architecture:  Unknown/Multiple
  Failure:  Documentation bug  |   Testcase:  
Blockedby: |   Blocking:  
  Related: |  
---+

Comment(by ezyang):

 Cooking up a docu 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] #4900: DEPENDS pragma

2012-01-17 Thread GHC

#4900: DEPENDS pragma
---+
  Reporter:  cdsmith   |  Owner:  
  Type:  feature request   | Status:  new 
  Priority:  normal|  Milestone:  7.6.1   
 Component:  Build System  |Version:  
Resolution:|   Keywords:  
Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  | Difficulty:  
  Testcase:  TH_Depends|  Blockedby:  
  Blocking:|Related:  
---+

Comment(by shelarcy):

 I found another problem. GHC 7.4.1 RC 1 doesn't export addDependentFile
 function.

  * http://www.haskell.org/ghc/dist/stable/docs/html/libraries/template-
 haskell-2.7.0.0/Language-Haskell-TH-Syntax.html

-- 
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] #5624: Delay Errors Until Runtime

2012-01-17 Thread GHC

#5624: Delay Errors Until Runtime
---+
  Reporter:  atnnn |  Owner:  atnnn   
  Type:  feature request   | Status:  closed  
  Priority:  high  |  Milestone:  7.6.1   
 Component:  Compiler  |Version:  7.3 
Resolution:  fixed |   Keywords:  
Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  | Difficulty:  Unknown 
  Testcase:|  Blockedby:  
  Blocking:|Related:  
---+

Comment(by simonmar):

 See also #5791.

-- 
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] #5791: Defer other kinds of errors until runtime, not just type errors

2012-01-17 Thread GHC

#5791: Defer other kinds of errors until runtime, not just type errors
-+--
Reporter:  simonmar  |   Owner:  
Type:  task  |  Status:  new 
Priority:  normal|   Milestone:  7.6.1   
   Component:  Compiler  | Version:  7.2.2   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:  5778  |  
-+--
Description changed by simonmar:

Old description:

> In #5778 we added `-fdefer-type-errors` to turn type errors into
> warnings.  We can do this for other kinds of errors too, notably out-of-
> scope errors, and there are plenty more errors that can be deferred by
> replacing the erroneous subexpression by a call to `error`.

New description:

 In #5624 we added `-fdefer-type-errors` to turn type errors into warnings.
 We can do this for other kinds of errors too, notably out-of-scope errors,
 and there are plenty more errors that can be deferred by replacing the
 erroneous subexpression by a call to `error`.

--

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

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

[GHC] #5791: Defer other kinds of errors until runtime, not just type errors

2012-01-17 Thread GHC

#5791: Defer other kinds of errors until runtime, not just type errors
-+--
Reporter:  simonmar  |   Owner:  
Type:  task  |  Status:  new 
Priority:  normal|   Milestone:  7.6.1   
   Component:  Compiler  | Version:  7.2.2   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:  5778  |  
-+--
 In #5778 we added `-fdefer-type-errors` to turn type errors into warnings.
 We can do this for other kinds of errors too, notably out-of-scope errors,
 and there are plenty more errors that can be deferred by replacing the
 erroneous subexpression by a call to `error`.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

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

Re: [GHC] #5624: Delay Errors Until Runtime

2012-01-17 Thread GHC

#5624: Delay Errors Until Runtime
---+
  Reporter:  atnnn |  Owner:  atnnn   
  Type:  feature request   | Status:  closed  
  Priority:  high  |  Milestone:  7.6.1   
 Component:  Compiler  |Version:  7.3 
Resolution:  fixed |   Keywords:  
Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  | Difficulty:  Unknown 
  Testcase:|  Blockedby:  
  Blocking:|Related:  
---+
Changes (by simonpj):

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


Comment:

 Thank you for suggesting the idea.  It's done!

 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] #5742: compiler option -XDoRec crash

2012-01-17 Thread GHC

#5742: compiler option -XDoRec crash
---+
Reporter:  Huenniger   |   Owner:  simonpj   
Type:  bug |  Status:  new   
Priority:  normal  |   Milestone:  7.6.1 
   Component:  Compiler| Version:  7.2.1 
Keywords:  frisby recusive do -XDoRec  |  Os:  Unknown/Multiple  
Architecture:  x86 | Failure:  Compile-time crash
  Difficulty:  Unknown |Testcase:
   Blockedby:  |Blocking:
 Related:  |  
---+
Changes (by simonpj):

  * owner:  => simonpj


Comment:

 I'm on this

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

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

Re: [GHC] #5790: Missing document about .eventlog's u flag

2012-01-17 Thread GHC

#5790: Missing document about .eventlog's u flag
---+
 Reporter:  shelarcy   |  Owner:  
 Type:  bug| Status:  new 
 Priority:  normal |  Component:  Documentation   
  Version:  7.4.1-rc1  |   Keywords:  
   Os:  Unknown/Multiple   |   Architecture:  Unknown/Multiple
  Failure:  Documentation bug  |   Testcase:  
Blockedby: |   Blocking:  
  Related: |  
---+
Changes (by shelarcy):

 * cc: shelarcy@… (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] #5790: Missing document about .eventlog's u flag

2012-01-17 Thread GHC

#5790: Missing document about .eventlog's u flag
---+
 Reporter:  shelarcy   |  Owner:  
 Type:  bug| Status:  new 
 Priority:  normal |  Component:  Documentation   
  Version:  7.4.1-rc1  |   Keywords:  
   Os:  Unknown/Multiple   |   Architecture:  Unknown/Multiple
  Failure:  Documentation bug  |   Testcase:  
Blockedby: |   Blocking:  
  Related: |  
---+
 GHC 7.4.1 RC 1 User's Guide and Debug.Trace modules' document doesn't
 describe -l option's u flag.

  * http://www.haskell.org/pipermail/cvs-ghc/2011-October/067200.html
  * http://www.haskell.org/ghc/dist/stable/docs/html/libraries/base-4.5.0.0
 /Debug-Trace.html#v:traceEvent
  * http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/runtime-
 control.html#rts-eventlog

 ThreadScope tutrial already shows u flag. So, I think this is important
 flag.

  * http://www.haskell.org/haskellwiki/ThreadScope_Tour/RTS

-- 
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] #5788: Missing document about RTS's -T option

2012-01-17 Thread GHC

#5788: Missing document about RTS's -T option
---+
 Reporter:  shelarcy   |  Owner:  ezyang  
 Type:  bug| Status:  new 
 Priority:  normal |  Component:  Documentation   
  Version:  7.4.1-rc1  |   Keywords:  
   Os:  Unknown/Multiple   |   Architecture:  Unknown/Multiple
  Failure:  Documentation bug  |   Testcase:  
Blockedby: |   Blocking:  
  Related: |  
---+
Changes (by tibbe):

  * owner:  => ezyang


Comment:

 Edward, could you please take a look?

-- 
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] #5789: Bad link to documentation

2012-01-17 Thread GHC

#5789: Bad link to documentation
--+-
 Reporter:  dsf   |  Owner:  
 Type:  bug   | Status:  new 
 Priority:  normal|  Component:  libraries/pretty
  Version:  7.2.2 |   Keywords:  
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
  Failure:  None/Unknown  |   Testcase:  
Blockedby:|   Blocking:  
  Related:|  
--+-
 The paper "The Design of a Pretty-printing Library" referenced on the
 front page of the pretty printing package documentation is not accessable:
 http://www.cs.chalmers.se/~rjmh/Papers/pretty.ps

-- 
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] #5788: Missing document about RTS's -T option

2012-01-17 Thread GHC

#5788: Missing document about RTS's -T option
---+
 Reporter:  shelarcy   |  Owner:  
 Type:  bug| Status:  new 
 Priority:  normal |  Component:  Documentation   
  Version:  7.4.1-rc1  |   Keywords:  
   Os:  Unknown/Multiple   |   Architecture:  Unknown/Multiple
  Failure:  Documentation bug  |   Testcase:  
Blockedby: |   Blocking:  
  Related: |  
---+
 Users Guide doesn't describe RTS's -T option except 7.4.1's release note.

  * http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/runtime-
 control.html#rts-options-gc
  *
 
http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/release-7-4-1.html#id525874

 Please add document about RTS's -T option in "Running a compiled program"
 section.

-- 
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] #5775: Inconsistency in demand analysis

2012-01-17 Thread GHC

#5775: Inconsistency in demand analysis
-+--
Reporter:  rl|   Owner: 
Type:  bug   |  Status:  new
Priority:  normal|   Milestone:  7.4.2  
   Component:  Compiler  | Version:  7.5
Keywords:|  Os:  Unknown/Multiple   
Architecture:  Unknown/Multiple  | Failure:  Runtime performance bug
  Difficulty:  Unknown   |Testcase: 
   Blockedby:|Blocking: 
 Related:|  
-+--

Comment(by simonpj):

 Maybe fragility only happens with `unsafePerformIO`. I'm not certain.

-- 
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] #5779: SPECIALISE pragma generates wrong activations

2012-01-17 Thread GHC

#5779: SPECIALISE pragma generates wrong activations
--+-
  Reporter:  rl   |  Owner:  
  Type:  bug  | Status:  closed  
  Priority:  normal   |  Milestone:  
 Component:  Compiler |Version:  7.5 
Resolution:  fixed|   Keywords:  
Os:  Unknown/Multiple |   Architecture:  Unknown/Multiple
   Failure:  Runtime performance bug  | Difficulty:  Unknown 
  Testcase:   |  Blockedby:  
  Blocking:   |Related:  
--+-
Changes (by simonpj):

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


Comment:

 OK I added the warnings

-- 
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] #5779: SPECIALISE pragma generates wrong activations

2012-01-17 Thread GHC

#5779: SPECIALISE pragma generates wrong activations
--+-
  Reporter:  rl   |  Owner:  
  Type:  bug  | Status:  new 
  Priority:  normal   |  Milestone:  
 Component:  Compiler |Version:  7.5 
Resolution:   |   Keywords:  
Os:  Unknown/Multiple |   Architecture:  Unknown/Multiple
   Failure:  Runtime performance bug  | Difficulty:  Unknown 
  Testcase:   |  Blockedby:  
  Blocking:   |Related:  
--+-

Comment(by simonpj@…):

 commit 6acf6cd7a8156b40979321ff94fe836736b46175
 {{{
 Author: Simon Peyton Jones 
 Date:   Tue Jan 17 16:01:16 2012 +

 Warn when a SPECIALISE pragma gives rise to a totally inactive rule
 See Trac #5779

  compiler/deSugar/DsBinds.lhs   |   62
 ---
  compiler/typecheck/TcBinds.lhs |3 +-
  2 files changed, 40 insertions(+), 25 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] #5776: Rule matching regression

2012-01-17 Thread GHC

#5776: Rule matching regression
-+--
Reporter:  rl|   Owner:
Type:  bug   |  Status:  merge 
Priority:  normal|   Milestone:  7.4.2 
   Component:  Compiler  | Version:  7.5   
Keywords:|  Os:  Unknown/Multiple  
Architecture:  Unknown/Multiple  | Failure:  Runtime performance bug   
  Difficulty:  Unknown   |Testcase:  simplCore/should_compile/T5776
   Blockedby:|Blocking:
 Related:|  
-+--

Comment(by rl):

 Thanks, it fuses now!

-- 
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] #5775: Inconsistency in demand analysis

2012-01-17 Thread GHC

#5775: Inconsistency in demand analysis
-+--
Reporter:  rl|   Owner: 
Type:  bug   |  Status:  new
Priority:  normal|   Milestone:  7.4.2  
   Component:  Compiler  | Version:  7.5
Keywords:|  Os:  Unknown/Multiple   
Architecture:  Unknown/Multiple  | Failure:  Runtime performance bug
  Difficulty:  Unknown   |Testcase: 
   Blockedby:|Blocking: 
 Related:|  
-+--

Comment(by rl):

 Hmm, isn't it only fragile in the presence of `unsafePerformIO` and
 friends (which is what `idx` in my example does)? If so, does it really
 matter? If I use `unsafePerformIO`, I'm on my own!

 This whole example is really an artefact of `Storable` living in `IO`
 rather than in `ST`. It seems that is causing even more problems than I
 realised.

-- 
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] #5775: Inconsistency in demand analysis

2012-01-17 Thread GHC

#5775: Inconsistency in demand analysis
-+--
Reporter:  rl|   Owner: 
Type:  bug   |  Status:  new
Priority:  normal|   Milestone:  7.4.2  
   Component:  Compiler  | Version:  7.5
Keywords:|  Os:  Unknown/Multiple   
Architecture:  Unknown/Multiple  | Failure:  Runtime performance bug
  Difficulty:  Unknown   |Testcase: 
   Blockedby:|Blocking: 
 Related:|  
-+--

Comment(by simonpj):

 OK I understand what is happening here.  Consider this:
 {{{
 f x = do { writeMutVar v 3
  ; if x then ... else .. }
 foo xs = catch (f (head xs))
(\_ -> readMutVar v)
 }}}
 Question: can I use call-value for `f`?  Is `f` strict in `x`?

 Well, when you call `f`, it'll certainly evalute `x` (I'm going to ignore
 the state-token bit here; it's not the point.)  But
  * if you use call-by-value, the the call `foo []` will throw an exception
 ''before'' executing the `writeMutVar`.
  * if you use cally-by-need, the call `foo []` will throw an exception
 only ''after'' executing the `writeMutVar`.
 The difference is observable.

 It's even more stark if in instead of `writeMutVar` you have `throwIO`, so
 that execution should not proceed beyond the `throwIO`.

 Tickets #148 and #1592 concerned exactly this point. The fix in #148
 (''nine'' years ago!) added a grotesque HACK in the demand analyser,
 commented thus:
 {{{
 -- There's a hack here for I/O operations.  Consider
 --  case foo x s of { (# s, r #) -> y }
 -- Is this strict in 'y'.  Normally yes, but what if 'foo' is an
 I/O
 -- operation that simply terminates the program (not in an
 erroneous way)?
 -- In that case we should not evaluate y before the call to 'foo'.
 -- Hackish solution: spot the IO-like situation and add a virtual
 branch,
 -- as if we had
 --  case foo x s of
 -- (# s, r #) -> y
 -- other  -> return ()
 -- So the 'y' isn't necessarily going to be evaluated
 --
 -- A more complete example (Trac #148, #1592) where this shows up
 is:
 --  do { let len =  ;
 -- ; when (...) (exitWith ExitSuccess)
 -- ; print len }
 }}}
 Now, Roman has discovered something else.
  * Not only is the hack unsavory,
  * not only does it make `loop` lazy when it should be strict,
  * but in addition it is incredibly fragile.
 By not-inlining `f` the hack doesn't fire, and `loop` gets stricter!  This
 is simply unacceptable.

 I don't really know what the right thing to do is.  I'm very inclined
 simply to remove the hack and see whether anyone complains.  But I'm open
 to suggestions.

-- 
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] #5776: Rule matching regression

2012-01-17 Thread GHC

#5776: Rule matching regression
-+--
Reporter:  rl|   Owner:
Type:  bug   |  Status:  merge 
Priority:  normal|   Milestone:  7.4.2 
   Component:  Compiler  | Version:  7.5   
Keywords:|  Os:  Unknown/Multiple  
Architecture:  Unknown/Multiple  | Failure:  Runtime performance bug   
  Difficulty:  Unknown   |Testcase:  simplCore/should_compile/T5776
   Blockedby:|Blocking:
 Related:|  
-+--
Changes (by simonpj):

  * status:  new => merge
  * testcase:  => simplCore/should_compile/T5776


Comment:

 Thanks for spotting this Roman.  I've fixed it and added a resgression
 test.

 Ian: pls merge.

 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] #5776: Rule matching regression

2012-01-17 Thread GHC

#5776: Rule matching regression
-+--
Reporter:  rl|   Owner: 
Type:  bug   |  Status:  new
Priority:  normal|   Milestone:  7.4.2  
   Component:  Compiler  | Version:  7.5
Keywords:|  Os:  Unknown/Multiple   
Architecture:  Unknown/Multiple  | Failure:  Runtime performance bug
  Difficulty:  Unknown   |Testcase: 
   Blockedby:|Blocking: 
 Related:|  
-+--

Comment(by simonpj@…):

 commit f002a461768cb334355c17053dcd331aa9ed1e06
 {{{
 Author: Simon Peyton Jones 
 Date:   Tue Jan 17 12:15:26 2012 +

 Do not combine dictionaries in the EvVarCache when simplEqsOnly is on

 This fixes Trac #5776; the background is in
 Note [Simplifying RULE lhs constraints] in TcSimplify

  compiler/typecheck/TcInteract.lhs |   67
 +
  1 files changed, 38 insertions(+), 29 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] #5785: Test failures on i386 with LLVM backend

2012-01-17 Thread GHC

#5785: Test failures on i386 with LLVM backend
-+--
 Reporter:  dterei   |  Owner:  dterei  
 Type:  bug  | Status:  new 
 Priority:  normal   |  Component:  Compiler (LLVM) 
  Version:  7.4.1-rc1|   Keywords:  
   Os:  Unknown/Multiple |   Architecture:  Unknown/Multiple
  Failure:  Incorrect result at runtime  |   Testcase:  
Blockedby:   |   Blocking:  
  Related:  #5757|  
-+--
Description changed by dterei:

Old description:

> Currently we get the following testsuite results on i386:
>
> {{{
> OVERALL SUMMARY for test run started at Fri Jan 13 22:25:17 UTC 2012
>
> 3195 total tests, which gave rise to
>15839 test cases, of which
>0 caused framework failures
> 3431 were skipped
>
>12083 expected passes
>  182 had missing libraries
>  132 expected failures
>1 unexpected passes
>   10 unexpected failures
>
> Unexpected passes:
>module/mod175  mod175 (normal)
>
> Unexpected failures:
>codeGen/should_runcgrun071 [bad stdout] (optllvm)
>dph/diophantine   dph-diophantine-copy-opt [bad exit code]
> (normal,threaded1,threaded2)
>driver/recomp006  recomp006 [bad stderr] (normal)
>ffi/should_runffi018 [bad stdout] (optllvm)
>ghc-api/apirecomp001  apirecomp001 [bad stderr] (normal)
>ghci/scripts  Defer02 [bad stdout] (ghci)
>lib/should_runenum02 [bad stdout] (optllvm)
>numeric/should_runarith011 [bad stdout] (optllvm)
> }}}
>
> Need to fix these

New description:

 Currently we get the following testsuite results on i386:

 {{{
 OVERALL SUMMARY for test run started at Fri Jan 13 22:25:17 UTC 2012

 3195 total tests, which gave rise to
15839 test cases, of which
0 caused framework failures
 3431 were skipped

12083 expected passes
  182 had missing libraries
  132 expected failures
1 unexpected passes
   10 unexpected failures

 Unexpected passes:
module/mod175  mod175 (normal)

 Unexpected failures:
codeGen/should_runcgrun071 [bad stdout] (optllvm)
dph/diophantine   dph-diophantine-copy-opt [bad exit code]
 (normal,threaded1,threaded2)
driver/recomp006  recomp006 [bad stderr] (normal)
ffi/should_runffi018 [bad stdout] (optllvm)
ghc-api/apirecomp001  apirecomp001 [bad stderr] (normal)
ghci/scripts  Defer02 [bad stdout] (ghci)
lib/should_runenum02 [bad stdout] (optllvm)
numeric/should_runarith011 [bad stdout] (optllvm)
 }}}

 Need to fix the LLVM failures:
 {{{
codeGen/should_runcgrun071 [bad stdout] (optllvm)
ffi/should_runffi018 [bad stdout] (optllvm)
lib/should_runenum02 [bad stdout] (optllvm)
numeric/should_runarith011 [bad stdout] (optllvm)
 }}}

 All seem to be incorrect results produced (no segfautls!).

--

-- 
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] #5782: llvm --enable-tbaa forces LLVM to be 2.9 or above

2012-01-17 Thread GHC

#5782: llvm --enable-tbaa forces LLVM to be 2.9 or above
---+
Reporter:  pmonday |Owner:  dterei   
Type:  bug |   Status:  closed   
Priority:  normal  |Component:  Compiler (LLVM)  
 Version:  7.5 |   Resolution:  fixed
Keywords:  |   Os:  Linux
Architecture:  x86_64 (amd64)  |  Failure:  GHC rejects valid program
Testcase:  |Blockedby:   
Blocking:  |  Related:   
---+
Changes (by dterei):

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


Comment:

 Fixed in 878371810de61632d58962608fb3db588d9c2fbd.

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

45 matches

Mail list logo