[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-gsl] [bug #25413] [patch] monte test failure under mingw

From: Guido De Rosa
Subject: [Bug-gsl] [bug #25413] [patch] monte test failure under mingw
Date: Sat, 31 Jan 2009 16:35:11 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv: Gecko/2008120122 Firefox/3.0.5 (.NET CLR 3.5.30729)

Follow-up Comment #4, bug #25413 (project gsl):

Excess precision problems are not not MinGW specific, they are common to the
x86 architecture. This sort of "bug" is regularly reported to the gcc tracker,
and regularly closed or suspended in a "won't fix" state. 

As far as I understand, relying on extended precision on x86 is not safe;
serious practical consequences may be rare, yet unpredictable.

http://arxiv.org/PS_cache/cs/pdf/0701/0701192v5.pdf (sec 3.1)

There are several (tested) way to fix/workaround this in GSL without the
performance loss of -ffloat-store.

1) -msse[{2|3}] -mfpmath=sse (on Pentium3, Athlon XP and newer)
SSE registers work better than x87 FPU and give better performance. This is
the best choice, when possible (and, for the records, is the default gcc
behavior on x86_64).

When SSE is not available:

2) force the FPU to IEEE standard precision

2.1) for example:

--- vegas.c     2008-11-29 17:42:43.000000000 +0100
+++ vegas.c.new 2009-01-31 15:31:43.703125000 +0100
@@ -56,6 +56,7 @@
 /* standard headers */
 #include <math.h>
 #include <stdio.h>
+#include <fenv.h>
 /* gsl headers */
 #include <gsl/gsl_math.h>
@@ -502,6 +503,9 @@
   state->bins = state->bins_max;
   state->ostream = stdout;
+  /*  53-bit mantissa */
+  feupdateenv(FE_PC53_ENV);
   return GSL_SUCCESS;

where $(MINGW_prefix)/include/fenv.h reads:

/* The floating point environment set by MSVCRT _fpreset (53-bit mantissa)
#define FE_PC53_ENV ((const fenv_t *)-2)

2.2) equivalently, link libglsmonte to $(MINGW_prefix)/lib/CRT_fp8.o

2.3) better, write ieee-utils/fp-win32.c to implement gsl_ieee_set_mode(),
then set GSL_IEEE_MODE as needed.

Naturally, there should be a way to integrate all (or part of) this stuff
into the autoconf infrastructure.



Reply to this item at:


  Messaggio inviato con/da Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]