ANNOUNCE: GHC 6.12.3 Release Candidate 1

[Simon Marlow]

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