[nightly] 23-Feb-2009 build of HEAD on i386-unknown-linux (cam-02-unx.europe.corp.microsoft.com)

2009-02-23 Thread GHC Build Reports
Build description = HEAD on i386-unknown-linux (cam-02-unx.europe.corp.microsoft.com) Build location= /playpen/simonmar/nightly/HEAD Build config file = /home/simonmar/nightly/site/msrc/conf-HEAD-cam-02-unx Nightly build started on cam-02-unx at Mon Feb 23 18:00:01 GMT 2009. checking out

[nightly] 23-Feb-2009 build of HEAD on x86_64-unknown-linux (cam-04-unx.europe.corp.microsoft.com)

2009-02-23 Thread GHC Build Reports
Build description = HEAD on x86_64-unknown-linux (cam-04-unx.europe.corp.microsoft.com) Build location= /64playpen/simonmar/nightly/HEAD-cam-04-unx Build config file = /home/simonmar/nightly/site/msrc/conf-HEAD-cam-04-unx Nightly build started on cam-04-unx at Mon Feb 23 19:00:02 GMT 2009. **

Re: x86_64 ghc on Mac OS

2009-02-23 Thread Ben Lippmeier
On 24/02/2009, at 12:18 PM, Daniel Peebles wrote: extern __thread gc_thread* gct Yeah, but from what I understand of the __thread for thread-local storage, it seems rather ELF-specific. Attempting to compile code that uses it on (my) Mac OS (i.e., MachO instead of ELF) results in a "thread-lo

Re: x86_64 ghc on Mac OS

2009-02-23 Thread Daniel Peebles
On Mon, Feb 23, 2009 at 8:05 PM, Ben Lippmeier wrote: > > On 24/02/2009, at 11:37 AM, Daniel Peebles wrote: >> >> I was told in #ghc on freenode to start with an unregistered build, >> but that seems to fail in compiler/main/DynFlags.hs, as the Platform >> module doesn't work in an unregistered bu

Re: x86_64 ghc on Mac OS

2009-02-23 Thread Ben Lippmeier
On 24/02/2009, at 11:37 AM, Daniel Peebles wrote: I was told in #ghc on freenode to start with an unregistered build, but that seems to fail in compiler/main/DynFlags.hs, as the Platform module doesn't work in an unregistered build. That'll be my fault. In the Cabal file the Platform.hs module

x86_64 ghc on Mac OS

2009-02-23 Thread Daniel Peebles
Hi all, I'm looking to get a 64-bit build of ghc (one that produces 64-bit code, that is) for Mac OS, and was wondering if anyone on this list knew what specific things are preventing such a build? According to the Apple documentation (http://is.gd/kBLv) Mac OS's 64-bit calling conventions are pre

patch applied (nofib): add parallel version of spectral/mandel

2009-02-23 Thread Simon Marlow
Mon Feb 23 05:26:41 PST 2009 Simon Marlow * add parallel version of spectral/mandel Ignore-this: abed7d2991cd282fad9927173a756b56 A ./parallel/mandel/ A ./parallel/mandel/Main.lhs A ./parallel/mandel/Makefile A ./parallel/mandel/Mandel.lhs A ./parallel/mandel/PortablePixm

patch applied (nofib): use parBuffer

2009-02-23 Thread Simon Marlow
Mon Feb 23 05:25:13 PST 2009 Simon Marlow * use parBuffer Ignore-this: 9759647cce8497ab862097ab3b6c196c M ./parallel/ray/Main.lhs -6 +66 View patch online: http://darcs.haskell.org/nofib/_darcs/patches/20090223132513-12142-68ad07251abb9a0fdedee7ba2ddedb457d39ffd7.gz ___

Re: patch applied (ghc): Fix an off-by-one; fixes the second bug in trac #3001

2009-02-23 Thread Simon Marlow
Ian Lynagh wrote: On Thu, Feb 19, 2009 at 10:52:28AM +, Simon Marlow wrote: Ian Lynagh wrote: Wed Feb 18 15:56:20 PST 2009 Ian Lynagh * Fix an off-by-one; fixes the second bug in trac #3001 M ./rts/LdvProfile.h -1 +1 Nice catch - though the off-by-one is actually at the call site (I

Daily report for stable

2009-02-23 Thread BuildBot Collator
Build results: x86 Linux stable:lost x86 Windows stable: pass lost x86 Windows stable fast: pass pass pass pass pass pass lost x86-64 Linux stable: pass Old unexpected test passes: unicode001 1 kili stable unicode002 1 kili stable New unexpected test failures: brea