On 13/07/2007, at 22:33, Simon Marlow wrote:
Pepe Iborra wrote:
I will be looking at them during today and tomorrow.
print022 seems to be failing on some architectures but not in
others, if I recall correctly, and for break017 I want to verify
that the output is consistent among architectures, and then accept
it.
I'm pretty sure the output from these two tests (print022 and
break017) varies non-deterministically.
print022 was an expected fail before, and it was failing on several
of the nightly builds (and still is). It succeeds during most
"validate" runs, though. I suspect the difference is due to
whether stage2 is compiled with optimisation. Can you try a stage
2 with and without optimisation and see if this happens for you?
This used to be the case, but I thought it had been addressed by this
patch:
Sun May 20 00:05:26 CEST 2007 Pepe Iborra <[EMAIL PROTECTED]>
* Rewrite the unsafe code dealing with unboxed primitives in
RtClosureInspect
On a closer look, it looks like the test fails only in 64bit
architectures. That is a likely explanation. I have a tentative fix
(crosses fingers) that I just sent Igloo's way for testing, since I
don't have access to a x86_64 box here.
break017 is strange - I was able to change the output merely by
adding a comment to the script. It might be related to print022, I
guess.
I haven't been able to figure out this one. There are two possible
outputs, which are both legal I believe, and the one you get varies
between architectures, and it seems to also vary in the same arch if
stage2 is compiled without optimisation.
I have tried to localise the problem (I'm not sure there is a problem
here btw) in a smaller test, with no luck. Sorry, but I've given up
for the moment.
Thanks for addinng tickets for the other failures. The result001
test I know about; I don't think it's easy to fix, unfortunately.
Yep, I did so in order to close #1457.
Cheers
pepe
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
