Re: [GHC] #4048: ghc-pkg should check for existence of extra-libraries

2011-03-04 Thread GHC 
#4048: ghc-pkg should check for existence of extra-libraries
-+--
Reporter:  simonmar  |Owner: 
Type:  bug   |   Status:  new
Priority:  normal|Milestone:  7.0.2  
   Component:  Package system|  Version:  6.12.2 
Keywords:| Testcase: 
   Blockedby:|   Difficulty:  Easy (less than 1 hour)
  Os:  Unknown/Multiple  | Blocking: 
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown   
-+--
Changes (by rbharath):

  * owner:  rbharath =>


-- 
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] #68: Warnings for unitialized fields

2011-03-04 Thread GHC 
#68: Warnings for unitialized fields
--+-
  Reporter:  nobody   |  Owner:  
  Type:  feature request  | Status:  infoneeded  
  Priority:  normal   |  Milestone:  _|_ 
 Component:  Compiler |Version:  None
Resolution:  None |   Keywords:  warnings
  Testcase:   |  Blockedby:  
Difficulty:  Easy (less than 1 hour)  | Os:  Unknown/Multiple
  Blocking:   |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown |  
--+-

Comment(by simonpj):

 Thanks for contriubting a patch.

 However, I'm not clear of the original intent here.  Consider
 {{{
 data T = T { x,y::Int }
 f = T { x = 3 }
 g = T {}
 }}}
 It would be very odd to get a warning from `f` but not from `g`.  I'm not
 sure this is what the original requester was asking.  I thought he didn't
 want a warning when `T` had zero fields -- and indeed you don't get a
 warning then.

 Puzzled.

 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] #4995: Compiling pandoc with llvm backend fails with panic

2011-03-04 Thread GHC 
#4995: Compiling pandoc with llvm backend fails with panic
+---
Reporter:  jgm  |   Owner:  dterei 
Type:  bug  |  Status:  new
Priority:  normal   |   Component:  Compiler (LLVM)
 Version:  7.0.2|Keywords:  llvm pandoc
Testcase:   |   Blockedby: 
  Os:  MacOS X  |Blocking: 
Architecture:  x86  | Failure:  None/Unknown   
+---

Comment(by jgm):

 I've got llvm version 2.8.

-- 
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] #4995: Compiling pandoc with llvm backend fails with panic

2011-03-04 Thread GHC 
#4995: Compiling pandoc with llvm backend fails with panic
+---
Reporter:  jgm  |   Owner:  dterei 
Type:  bug  |  Status:  new
Priority:  normal   |   Component:  Compiler (LLVM)
 Version:  7.0.2|Keywords:  llvm pandoc
Testcase:   |   Blockedby: 
  Os:  MacOS X  |Blocking: 
Architecture:  x86  | Failure:  None/Unknown   
+---
Changes (by dterei):

  * owner:  davidterei@… => dterei


Comment:

 OK I'll take a look, seems to be a bug with the LLVM mangler. Its a hard
 process for me to test on OS X so unfortunately this bug seems to have
 slipped through.

 Which version of LLVM are you using? If you want to you should be fine
 compiling pandoc on a different platform then OSX.

-- 
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] #4370: Bring back monad comprehensions

2011-03-04 Thread GHC 
#4370: Bring back monad comprehensions
-+--
Reporter:  simonpj   |Owner:  nsch
Type:  feature request   |   Status:  patch   
Priority:  normal|Milestone:  7.4.1   
   Component:  Compiler  |  Version:  6.12.3  
Keywords:| Testcase:  
   Blockedby:|   Difficulty:  
  Os:  Unknown/Multiple  | Blocking:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--

Comment(by nsch):

 Patch for the testsuite added. One note: I've added a
 `expected_broken_for(4370, ['ghci','hpc'])` flag to all tests wich use the
 grouping statement, since ghci still fails with grouping statements…

 I also fixed a few bugs in the compiler (mostly minor bugs in the error
 messages) and will upload the new version aswell.

 Unless somebody comes up with a solution to that ghci error I'd suggest to
 apply these patches and open a separate bug ticket, so someone with the
 necessary expertise will be able to fix it. I will continue to try to fix
 that ghci bug, but currently I don't see why this happens at all (ghci
 even generates different core code, see http://npaste.de/zV/ (ghci) vs
 http://npaste.de/zW/ (ghc) – the `>>=` on line 31 of the ghci code makes
 no sense at all…).

 So, to commit these patches you should apply...

  * `monad-comprehensions-final.patch` and `mc-user-guide.patch` to the
 main repo
  * `mc-testsuite.patch` to the testsuite
  * `group_zip.patch` to the `base` package
  * `mc-cabal-extensions.patch` to the `Cabal` package

 The alpha version and that git commit can be ignored.

 And just to let you know, I'll be on vacations next week, so I won't be
 able to do any work. I'll add that wiki entry when I come back.

-- 
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] #4975: Windows binary's documentation directory hierarchy is broken

2011-03-04 Thread GHC 
#4975: Windows binary's documentation directory hierarchy is broken
-+--
Reporter:  shelarcy  |Owner:  
Type:  bug   |   Status:  new 
Priority:  normal|Milestone:  7.2.1   
   Component:  Build System  |  Version:  7.0.2   
Keywords:| Testcase:  
   Blockedby:|   Difficulty:  
  Os:  Windows   | Blocking:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--
Changes (by igloo):

  * milestone:  => 7.2.1


Comment:

 Thanks for the report.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

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

[GHC] #4995: Compiling pandoc with llvm backend fails with panic

2011-03-04 Thread GHC 
#4995: Compiling pandoc with llvm backend fails with panic
+---
Reporter:  jgm  |   Owner:  davidterei@…
Type:  bug  |  Status:  new 
Priority:  normal   |   Component:  Compiler (LLVM) 
 Version:  7.0.2|Keywords:  llvm pandoc 
Testcase:   |   Blockedby:  
  Os:  MacOS X  |Blocking:  
Architecture:  x86  | Failure:  None/Unknown
+---
 I decided to try compiling pandoc with the llvm backend (GHC 7.0.2 32 bit
 on Mac OSX 10.6).  I put -fllvm in Ghc-Options in the cabal file and did a
 'cabal install'.
 It failed eventually with the following message, which I am duly
 reporting:

 [14 of 37] Compiling Text.Pandoc.Readers.LaTeX (
 src/Text/Pandoc/Readers/LaTeX.hs, dist/build/pandoc/pandoc-
 tmp/Text/Pandoc/Readers/LaTeX.o )
 SpecConstr
 Function `$w$j{v s62TR} [lid]'
   has two call patterns, but the limit is 1
 Use -fspec-constr-count=n to set the bound
 Use -dppr-debug to see specialisations
 SpecConstr
 Function `$w$j{v s62TR} [lid]'
   has two call patterns, but the limit is 1
 Use -fspec-constr-count=n to set the bound
 Use -dppr-debug to see specialisations
 [...deleted more in that vein...]
 SpecConstr
 Function `$w$j{v s63cF} [lid]'
   has two call patterns, but the limit is 1
 Use -fspec-constr-count=n to set the bound
 Use -dppr-debug to see specialisations
 ghc: panic! (the 'impossible' happened)
   (GHC version 7.0.2 for i386-apple-darwin):
 LLvmMangler Cannot read"_c6"as it's not an Int

 Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

-- 
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] #2722: < when compiling with -O option with ghc-6.10.0.20081019

2011-03-04 Thread GHC 
#2722: < when compiling with -O option with ghc-6.10.0.20081019
-+--
  Reporter:  uwe |  Owner:
  Type:  bug | Status:  new   
  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 litoh):

 Turned out to be a bug in the Yampa library
 Concerning my test case, it was "a complete red herring" ;)

-- 
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] #2722: < when compiling with -O option with ghc-6.10.0.20081019

2011-03-04 Thread GHC 
#2722: < when compiling with -O option with ghc-6.10.0.20081019
-+--
  Reporter:  uwe |  Owner:
  Type:  bug | Status:  new   
  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   |  
-+--
Changes (by igloo):

  * owner:  simonpj =>
  * status:  closed => new
  * resolution:  invalid =>


Comment:

 We still need to fix the rules in the library that comes with GHC, so
 reopening 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] #2722: < when compiling with -O option with ghc-6.10.0.20081019

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

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


-- 
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] #4992: LLVM trashes registers for primitive calls

2011-03-04 Thread GHC 
#4992: LLVM trashes registers for primitive calls
--+-
  Reporter:  scpmw|  Owner:  davidterei@…
  Type:  bug  | Status:  closed  
  Priority:  normal   |  Milestone:  
 Component:  Compiler (LLVM)  |Version:  7.1 
Resolution:  invalid  |   Keywords:  
  Testcase:   |  Blockedby:  
Difficulty:   | Os:  Linux   
  Blocking:   |   Architecture:  x86_64 (amd64)  
   Failure:  Runtime crash|  
--+-
Changes (by dterei):

  * status:  patch => closed
  * resolution:  => invalid


Comment:

 Cool! I wouldn't say that not paying attention to live variables is
 perfectly safe though. The native code generator as I understand also
 relies on this saving and restoring of live registers to have already been
 done in the Cmm representation. The only reason it didn't crash on the
 same code I assume is that the code for the primitive call never touched
 the live registers. Its perfectly legal for it to do so though, so there
 are some cases with bigger primitive calls where it would fail for the
 native code generator. LLVM failed earlier as the registers are trashed to
 prevent code duplication and slowdown and as there was no save and restore
 in the Cmm LLVM correctly used the actually live registers for
 intermediate code in the function.

-- 
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] #4992: LLVM trashes registers for primitive calls

2011-03-04 Thread GHC 
#4992: LLVM trashes registers for primitive calls
+---
Reporter:  scpmw|Owner:  davidterei@…
Type:  bug  |   Status:  patch   
Priority:  normal   |Milestone:  
   Component:  Compiler (LLVM)  |  Version:  7.1 
Keywords:   | Testcase:  
   Blockedby:   |   Difficulty:  
  Os:  Linux| Blocking:  
Architecture:  x86_64 (amd64)   |  Failure:  Runtime crash   
+---

Comment(by scpmw):

 Okay, seems you are indeed right. Once registers are actually live, they
 get saved and the code does what it should.

 The root cause here was my GHC tinkering, which happened to generate
 primitive calls without paying attention to live variables - which is in
 itself perfectly safe except that LLVM codegen counts on this unnecessary
 register saving taking place in order to produce correct code. Whew,
 didn't expect that.

 Apologies for the confusion. I guess this can be closed, as the upsides
 have now been reduced to
 just less redundant code getting generated.

-- 
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] #4997: Ppi Claims - How To Obtain An Order Of Protection

2011-03-04 Thread GHC 
#4997: Ppi Claims - How To Obtain An Order Of Protection
+---
Reporter:  ppiclaims|   Owner:  jenny cool 
Type:  feature request  |  Status:  new
Priority:  normal   |   Component:  Compiler   
 Version:  7.0.2|Keywords:  ppi claims 
Testcase:   |   Blockedby: 
  Os:  HPUX |Blocking: 
Architecture:  arm  | Failure:  GHC doesn't work at all
+---
 
[[Image(http://www.moneyminds.co.uk/images/custom/1271346117_claim_back_money.jpg)]]

 There are thousand of insurance company all around the world and one of
 the popular company is the '''[http://www.ukppiclaims.org ppi claims]'''
 especially for those who are working they really know about this kind of
 insurance. There are so many thing that you will have the best as you
 wanted for your '''insurance''' and be one of the many that who have the
 protection that really indeed give people live life to the fullest. This
 article will going to give you some tips on how to obtain an order of
 protection from the ppi '''Claims'''.

 [[Image(http://static.guim.co.uk/sys-
 images/Guardian/Pix/commercial/2009/7/10/1247226980001/Close-up-of-some-
 coins-an-001.jpg)]]

 Obtaining an order protection from the
 '''[http://160.45.170.216:8081/trac/ticket/5676 ppi claims]''' is just an
 easy task all you need is to have enough time and effort to have this kind
 of protection from the '''PPI Company'''. The best thing that you should
 do so that you will be able to have the best '''PPI''' claim also good
 reason that there are so many thing that could have for your protection.

-- 
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] #4996: Ppi Claims - How To Obtain An Order Of Protection

2011-03-04 Thread GHC 
#4996: Ppi Claims - How To Obtain An Order Of Protection
+---
Reporter:  ppiclaims|   Owner:  jenny cool 
Type:  feature request  |  Status:  new
Priority:  normal   |   Component:  Compiler   
 Version:  7.0.2|Keywords:  ppi claims 
Testcase:   |   Blockedby: 
  Os:  HPUX |Blocking: 
Architecture:  arm  | Failure:  GHC doesn't work at all
+---
 [[Image(http://static.guim.co.uk/sys-
 images/Guardian/Pix/commercial/2009/7/10/1247226980001/Close-up-of-some-
 coins-an-001.jpg)]]

 There are thousand of insurance company all around the world and one of
 the popular company is the '''[http://www.ukppiclaims.org ppi claims]'''
 especially for those who are working they really know about this kind of
 insurance. There are so many thing that you will have the best as you
 wanted for your '''insurance''' and be one of the many that who have the
 protection that really indeed give people live life to the fullest. This
 article will going to give you some tips on how to obtain an order of
 protection from the ppi '''Claims'''.

 
[[Image(http://2.bp.blogspot.com/_iJWihNRtMEw/TOp8fyrSqXI/ADQ/_RvZZjlaETo/s1600/IMG_4540.JPG)]]

 Obtaining an order protection from the
 '''[http://160.45.170.216:8081/trac/ticket/5676 ppi claims]''' is just an
 easy task all you need is to have enough time and effort to have this kind
 of protection from the '''PPI Company'''. The best thing that you should
 do so that you will be able to have the best '''PPI''' claim also good
 reason that there are so many thing that could have for your protection.

-- 
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] #4995: Ppi Claims - How To Obtain An Order Of Protection

2011-03-04 Thread GHC 
#4995: Ppi Claims - How To Obtain An Order Of Protection
+---
Reporter:  ppiclaims|   Owner:  jenny cool 
Type:  feature request  |  Status:  new
Priority:  normal   |   Component:  Compiler   
 Version:  7.0.2|Keywords:  ppi claims 
Testcase:   |   Blockedby: 
  Os:  HPUX |Blocking: 
Architecture:  arm  | Failure:  GHC doesn't work at all
+---
 [[Image()]]

 There are thousand of insurance company all around the world and one of
 the popular company is the '''[http://www.ukppiclaims.org ppi claims]'''
 especially for those who are working they really know about this kind of
 insurance. There are so many thing that you will have the best as you
 wanted for your '''insurance''' and be one of the many that who have the
 protection that really indeed give people live life to the fullest. This
 article will going to give you some tips on how to obtain an order of
 protection from the ppi '''Claims'''.

 [[Image()]]

 Obtaining an order protection from the
 '''[http://160.45.170.216:8081/trac/ticket/5676 ppi claims]''' is just an
 easy task all you need is to have enough time and effort to have this kind
 of protection from the '''PPI Company'''. The best thing that you should
 do so that you will be able to have the best '''PPI''' claim also good
 reason that there are so many thing that could have for your protection.

-- 
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] #4970: time002 and time004 (ghci) test failures on OS X 64 bit

2011-03-04 Thread GHC 
#4970: time002 and time004 (ghci) test failures on OS X 64 bit
---+
Reporter:  gwright |   Owner:  gwright
Type:  bug |  Status:  patch  
Priority:  normal  |   Component:  GHCi   
 Version:  7.0.1   |Keywords: 
Testcase:  |   Blockedby: 
  Os:  MacOS X |Blocking: 
Architecture:  x86_64 (amd64)  | Failure:  Incorrect result at runtime
---+
Changes (by gwright):

  * status:  new => patch


-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

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

Re: [GHC] #4970: time002 and time004 (ghci) test failures on OS X 64 bit

2011-03-04 Thread GHC 
#4970: time002 and time004 (ghci) test failures on OS X 64 bit
---+
Reporter:  gwright |   Owner:  gwright
Type:  bug |  Status:  new
Priority:  normal  |   Component:  GHCi   
 Version:  7.0.1   |Keywords: 
Testcase:  |   Blockedby: 
  Os:  MacOS X |Blocking: 
Architecture:  x86_64 (amd64)  | Failure:  Incorrect result at runtime
---+

Comment(by gwright):

 Surprise! Not a relocation failure at all! I don't understand why it only
 occurs for the `ghci` tests, but I am able to fix the bug.

 Here's what's going on:

 I used the linker debug output to get the memory address of the call to
 `__hscore_gettimeofday`.  Then I poked around with `gdb`'s `x/i` command
 to get the memory addresses of the instructions just before and after the
 call. I set breakpoints at these instructions.  (This may seem roundabout,
 but more on that later.)

 I ran the `test002` program a number of times, looking for where the time
 of day was returned from `__hscore_gettimeofday`.  I guessed that the
 return values might be somewhere pointed to by the STG machine's `R1`
 (`$rbx` on `amd64`), and it is:
 {{{
 *Main> main

 Breakpoint 3, 0x0001061208d1 in ?? ()
 1: x/i $rip  0x1061208d1:   mov$0x0,%eax
 (gdb) p8 $rbx
 0x105d28178:0x302e302e322e302d
 0x105d28170:0x6d6972702d636867
 0x105d28168:0x10
 0x105d28160:0x101f34340 
 0x105d28158:0x8
 0x105d28150:0x0
 0x105d28148:0x10
 0x105d28140:0x101f34340 
 (gdb) c
 Continuing.

 Breakpoint 1, 0x0001061208db in ?? ()
 1: x/i $rip  0x1061208db:   mov%r14,-0x8(%rbp)
 (gdb) p8 $rbx
 0x105d28178:0x302e302e322e302d
 0x105d28170:0x6d6972702d636867
 0x105d28168:0x10
 0x105d28160:0x101f34340 
 0x105d28158:0xe300b
 0x105d28150:0x4d7118d0
 0x105d28148:0x10
 0x105d28140:0x101f34340 
 (gdb)
 }}}
 The lines at `$rbx + 16` (0x105d28150) and `$rbx + 24` (0x105d28158) hold
 the `sec` and `usec` values, respectively.  These are the seconds and
 microseconds since the Unix epoch on 1 Jan 1970.  The current seconds
 count isn't obvious; I had to run `date +%s` in a shell, converted the
 value to hex then looked at the memory pointed to by various registers to
 find something starting with `0x4d7...`.

 I tried to step through `__hscore_gettimeofday` to see the time values
 being written, but it doesn't work.  The `_gettimeofday` system call loops
 endlessly calling `_nanotime`.  I suspect that there is a consistency
 check to make sure the time returned is current, even if the process is
 interrupted or put to sleep.  Single stepping interrupts each instruction,
 causing `_gettimeofday` to chase its tail.

 However, on OS X we have a lucky break.  `gdb` on this platform has
 hardware watchpoints, so I can set a watchpoint on the memory location
 that the `usec` value is written to, and it won't cause significant
 overhead.  Here's a transcript with the watchpoint set:
 {{{
 *Main> main

 Breakpoint 3, 0x0001061208d1 in ?? ()
 1: x/i $rip  0x1061208d1:   mov$0x0,%eax
 (gdb) p8 $rbx
 0x105d283f8:0xc
 0x105d283f0:0x101f34340 
 0x105d283e8:0x8
 0x105d283e0:0x101f34340 
 0x105d283d8:0x322e302e33
 0x105d283d0:0x2e302d7961727261
 0x105d283c8:0x10
 0x105d283c0:0x101f34340 
 (gdb) watch * 0x105d283d8
 Hardware watchpoint 13: *4392649688
 (gdb) c
 Continuing.
 Hardware watchpoint 13: *4392649688

 Old value = 774909491
 New value = 735977
 0x7fe00337 in __gettimeofday ()
 1: x/i $rip  0x7fe00337 <__gettimeofday+87>:xor%eax,%eax
 (gdb) c
 Continuing.

 Breakpoint 1, 0x0001061208db in ?? ()
 1: x/i $rip  0x1061208db:   mov%r14,-0x8(%rbp)
 (gdb) p8 $rbx
 0x105d283f8:0xc
 0x105d283f0:0x101f34340 
 0x105d283e8:0x8
 0x105d283e0:0x101f34340 
 0x105d283d8:0x32000b3ae9
 0x105d283d0:0x4d700913
 0x105d283c8:0x10
 0x105d283c0:0x101f34340 
 (gdb)
 }}}
 Here we see that a sensible value for microseconds is stored to
 `0x105d283d8`, 735977 (`0xb3ae9`), or about three quarters of a second
 (look at the "`New value =`" line).  But after `__hscore_gettimeofday`
 returns, memory location `0x105d283d8` contains `0x32000b3ae9`.  The low
 order 32 bits are correct, but the high order 32 bits contain junk.
 Continuing from this point gives the "`picoseconds out of range`" error.

 The cause is simple, and not at all related to the linker.  In the
 `getClockTime` function in `libraries/old-time/System/Time.hsc`,
 {{{
 #elif HAVE_GETTIMEOFDAY
 getClockTime = do
   allocaBytes (#const sizeof(struct timeval)) $ \ p_timeval -> do
 throwErrnoIfMin

Re: [GHC] #4973: building ghc7.0.1.20110217 under x86 solaris fails

2011-03-04 Thread GHC 
#4973: building ghc7.0.1.20110217 under x86 solaris fails
--+-
  Reporter:  maeder   |  Owner: 
  Type:  bug  | Status:  new
  Priority:  highest  |  Milestone:  7.0.2  
 Component:  Compiler |Version:  7.0.1  
Resolution:   |   Keywords: 
  Testcase:   |  Blockedby: 
Difficulty:   | Os:  Solaris
  Blocking:   |   Architecture:  x86
   Failure:  Building GHC failed  |  
--+-

Comment(by maeder):

 The error of [comment:9 maeder] is still present in ghc-7.0.2. In order to
 build ghc-7.0.2 for SunOS 5.10 the "i386-unknown-solaris2 \" entry must be
 removed from `PlatformSupportsSharedLibs` in config.mk.in, otherwise
 config.mk will be wrongly generated for the installation, too (and fail).

-- 
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] #4370: Bring back monad comprehensions

2011-03-04 Thread GHC 
#4370: Bring back monad comprehensions
-+--
Reporter:  simonpj   |Owner:  nsch
Type:  feature request   |   Status:  patch   
Priority:  normal|Milestone:  7.2.1   
   Component:  Compiler  |  Version:  6.12.3  
Keywords:| Testcase:  
   Blockedby:|   Difficulty:  
  Os:  Unknown/Multiple  | Blocking:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--

Comment(by simonpj):

 Thanks for all your work here. I'm travelling at the moment, and then the
 ICFP deadline presses, but I'll review can commit  your patches for the
 upcoming 7.2 release.

 One thing: earlier in the ticket you give the desugaring rules.  Could you
 transfer them to a GHC wiki page, linked from the "Contributed
 documentation" section of
 http://hackage.haskell.org/trac/ghc/wiki/Commentary?  To make sense of it
 you, probably want to cut/paste a summary of the goal, and an overview of
 the implementation.  Nothing too detailed, becuase documentation separate
 from code tends to go out of date.  Just a road-map of where to look for
 the changes, and any "watch out for this" points you tripped over.
 Worth pointing back to this roadmap and the desugaring rules from comments
 in the code.

 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] #4370: Bring back monad comprehensions

2011-03-04 Thread GHC 
#4370: Bring back monad comprehensions
-+--
Reporter:  simonpj   |Owner:  nsch
Type:  feature request   |   Status:  patch   
Priority:  normal|Milestone:  7.2.1   
   Component:  Compiler  |  Version:  6.12.3  
Keywords:| Testcase:  
   Blockedby:|   Difficulty:  
  Os:  Unknown/Multiple  | Blocking:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--

Comment(by nsch):

 This patch adds `MonadComprehensions` to the `Language.Haskell.Extension`
 library of the `Cabal` package and fixes the only test in the testsuite
 that got broken by my monad comprehension patch (T4437).

 It also fixes some of the references to the user guide.

-- 
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] #4370: Bring back monad comprehensions

2011-03-04 Thread GHC 
#4370: Bring back monad comprehensions
-+--
Reporter:  simonpj   |Owner:  nsch
Type:  feature request   |   Status:  patch   
Priority:  normal|Milestone:  7.2.1   
   Component:  Compiler  |  Version:  6.12.3  
Keywords:| Testcase:  
   Blockedby:|   Difficulty:  
  Os:  Unknown/Multiple  | Blocking:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--

Comment(by nsch):

 The user guide documentation is done, patch attached.

 A compiled version is available at:
 http://n-sch.de/hdocs/ghc/html/users_guide/syntax-extns.html#monad-
 comprehensions

-- 
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] #4992: LLVM trashes registers for primitive calls

2011-03-04 Thread GHC 
#4992: LLVM trashes registers for primitive calls
+---
Reporter:  scpmw|Owner:  davidterei@…
Type:  bug  |   Status:  patch   
Priority:  normal   |Milestone:  
   Component:  Compiler (LLVM)  |  Version:  7.1 
Keywords:   | Testcase:  
   Blockedby:   |   Difficulty:  
  Os:  Linux| Blocking:  
Architecture:  x86_64 (amd64)   |  Failure:  Runtime crash   
+---

Comment(by scpmw):

 I can't simply attach what crashed for me because it requires a number of
 additional GHC patches to reproduce - all of which are ''very''
 experimental at this stage. I will have another go at reproducing it, the
 incomplete test case probably just needs one of the normally-saved
 registers to be live across "r" to fail.

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