Mon May 19 22:33:26 PDT 2008 Roman Leshchinskiy <[EMAIL PROTECTED]>
* Accept -fmethod-sharing
M ./tests/ghc-regress/ghci/scripts/ghci024.py +1
View patch online:
http://darcs.haskell.org/testsuite/_darcs/patches/20080520053326-b2b0a-21f6b5b3a5f5b6f69ba45d47247cffe45b648619.gz
Mon May 19 20:19:13 PDT 2008 Roman Leshchinskiy <[EMAIL PROTECTED]>
* Add -Odph
This is the optimisation level recommended when compiling DPH programs. At the
moment, it is equivalent to -O2 -fno-method-sharing -fdicts-cheap
-fmax-simplifier-iterations20 -fno-spec-constr-threshold.
Mon May 19 19:59:56 PDT 2008 Roman Leshchinskiy <[EMAIL PROTECTED]>
* Make -f[no-]method-sharing a dynamic flag
We want -Odph to be a dynamic flag and that should imply -fno-method-sharing.
This doesn't add a lot of complexity.
M ./compiler/main/DynFlags.hs +4
M ./compiler/main/S
I get the following two failures:
Unexpected failures:
ghci024(ghci)
num009(normal)
Recently, I tend to get unexpected failures every time I pull in
patches. What happened to the policy of running validate before pushing?
I thought we agreed that was a good idea?
In any case, I have n
Mon May 19 20:24:54 PDT 2008 Norman Ramsey <[EMAIL PROTECTED]>
* documentation for ZipDataflow
M ./compiler/cmm/ZipDataflow.hs -53 +237
View patch online:
http://darcs.haskell.org/ghc/_darcs/patches/20080520032454-39dff-472ad292ee0e176c1ca379c13e774774130b9457.gz
_
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 May 19 18:00:01 BST 2008.
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 Mon May 19 18:10:01 BST 2008.
checki
| So would you say this affects our standard idiom for strictifying things.
| The
|
| let !x = e in ... x ...
|
| form should be used now, for robustness reasons.
Yes, this is better than
let x = e in x `seq` ...x...
precisely because the former is invulnerable to valid but leak-indu
Build results:
kahl G5 Gentoo Linux stable: fail (failed darcs)
macgyver PPC OSX stable: pass
x86 Windows stable: fail (failed bindisttest)
x86 Windows stable fast: pass pass lost pass pass pass
x86-64 Linux stable: pass
Old unexpected test passes:
cg057 1 x86-64 Li
Build results:
x86-64 Linux head: fail (failed stage1)
x86 Windows head: fail (failed bindisttest)
x86 Windows head fast: pass pass pass
kahl G5 Gentoo Linux head: pass
tnaur PPC OSX head 2: fail (failed darcs)
x86-64 Linux head unreg: pass
Old unexpected test passes:
10 matches
Mail list logo