On 29/05/2010 15:07, Matthias Kilian wrote:
On Fri, May 28, 2010 at 10:05:36PM +0100, Simon Marlow wrote:
hReady002(ghci) ==> did not investigate yet. failure details below
This one is a known failure right now (I need to clean it up).
Good to know. Thanks for the info.
num009(normal,optc,hpc,optasm,ghci) ==> no idea. failure details below
Suspicious...
If in doubt, suspect OpenBSD here; this is not the first time I've seen strange differences between our math and the math on other systems. But it's reall strange that there are different failures for different ways. I'll try to find what's going on.
It used to be the case that OpenBSD by default put the FPU on x86 machines into 64-bit precision mode, whereas other platforms tend to leave it in the default 80-bit mode. The advantage of OpenBSD's approach is that FP results are more robust to compiler optimisations and suchlike, without having to use gcc's -ffloat-store option. The disadvantage is that some precision has been discarded, and the results are different to those on other platforms. Also, I believe 32-bit float operations are done at 64-bit precision on OpenBSD, which is a bit strange. In GHC we support -msse2 which avoids these problems by using the correct precision consistently, as long as your processor supports SSE2. You'd have to build all the libraries with -msse2 to get the full benefit. Cheers, Simon