Following the discussion in haskell-cafe, I tried changing the order of tests
in the Integral methods from:
a `rem` b
| b == 0 = divZeroError
| a == minBound && b == (-1) = overflowError
| otherwise = a `remInt` b
to
a `rem` b
|
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 Sat Mar 27 18:00:01 GMT 2010.
checking out
Build description = STABLE on i386-unknown-linux
(cam-02-unx.europe.corp.microsoft.com)
Build location= /playpen/simonmar/nightly/STABLE
Build config file = /home/simonmar/nightly/site/msrc/conf-STABLE-cam-02-unx
Nightly build started on cam-02-unx at Sat Mar 27 18:10:01 GMT 2010.
checki
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 Sat Mar 27 19:00:01 GMT 2010.
**
Build description = STABLE on x86_64-unknown-linux
(cam-04-unx.europe.corp.microsoft.com)
Build location= /64playpen/simonmar/nightly/STABLE-cam-04-unx
Build config file = /home/simonmar/nightly/site/msrc/conf-STABLE-cam-04-unx
Nightly build started on cam-04-unx at Sat Mar 27 19:10:01 GMT 20
On 28/03/2010, at 09:23, Ian Lynagh wrote:
> Are the dph tests expected to take large amounts of RAM while compiling?
I suspect so. The problem is that they inline almost everything, which results
in very large intermediate code. We haven't found a way to avoid this so far.
Roman
Hi all,
Are the dph tests expected to take large amounts of RAM while compiling?
It's very noticable when validate runs several at once while I'm doing
something else.
The numbers look like this:
dph-diophantine: 232M in use
dph-dotp: 61M in use
dph-primespj:338M in use
dph-quickhul
Sat Mar 27 11:21:26 PDT 2010 Ian Lynagh
* Fix the format specifier for Int64/Word64 on Windows
mingw doesn't understand %llu/%lld - it treats them as 32-bit rather
than 64-bit. We use %I64u/%I64d instead.
M ./includes/Rts.h +7
___
Cvs-ghc ma
Sat Mar 27 11:21:26 PDT 2010 Ian Lynagh
* Fix the format specifier for Int64/Word64 on Windows
mingw doesn't understand %llu/%lld - it treats them as 32-bit rather
than 64-bit. We use %I64u/%I64d instead.
M ./includes/Rts.h +7
___
Cvs-ghc ma
On Wed, Mar 24, 2010 at 12:55:23PM -0700, Ian Lynagh wrote:
> Tue Mar 23 15:13:25 PDT 2010 Ian Lynagh
> * Tweak the Makefile code for making .a libs; fixes trac #3642
> The main change is that, rather than using "xargs ar" we now put
> all the filenames into a file, and do "ar @file". This
10 matches
Mail list logo