ANNOUNCE: GHC 6.12.3 Release Candidate 1
marlowsd at gmail.com
Wed Jun 2 04:59:10 EDT 2010
On 29/05/2010 15:07, Matthias Kilian wrote:
> On Fri, May 28, 2010 at 10:05:36PM +0100, Simon Marlow wrote:
>>> ==> 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.
>>> ==> no idea. failure details below
> 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.
More information about the Glasgow-haskell-users