I've been having similar problems, and have put it down 'double' returning functions. Mostly c rtl functions as most gsl return status codes. At high optimization levels the accuracy of these functions is actually increased. Doubles are passed on the stack as 64-bit without optimization. If the compiler optimizes to pass and return with floating point registers then the function is given a free upgrade to a long double version (assuming the platform's FPU has 80bit registers). e.g. With optimizations
exp(x + 0.5) 80-bit guarded add is passed as 80 bit to exp. and (z + 0.5) * log(x) 80bit register return from log multiplied by an 80 bit guarded add result in register. Without optimization this type of code may be consistently in double precision, giving slightly less accurate results. So I'm wondering if some of these test case expected results are already loaded with precision errors. Regards, Greg. ----- Original Message ---- From: Brian Gough <[email protected]> To: Tasos Drosopoulos <[email protected]> Cc: [email protected] Sent: Friday, 14 August, 2009 5:20:06 AM Subject: Re: [Bug-gsl] gsl-1.12 make check failure with gcc-4.4.1 At Tue, 11 Aug 2009 12:29:46 +0000, Tasos Drosopoulos wrote: > make[2]: Entering directory `/home/drososa/gsl-1.12/integration' > FAIL: qawc(f459) elist (1.83292424966307774e-15 observed vs > 1.83308294820715351e-15 expected) [744] > FAIL: test > ... > > The error disappears when I compile with CFLAGS="-O" indicating an > overaggressive optimization (perhaps? on the side of the gcc-4.4.1 > compiler). I observed a similar pattern in the past with gcc-4.3.2 which > was fixed with gcc-4.3.3 (the one I am using now for my everyday work). > > If anyone has a Linux system using the same compiler please verify the > above. If the FAIL persists someone should inform the gcc people. I > would like to upgrade to a more recent gcc provided I can still do my > work (based heavily on gsl). Thanks for the bug report. I don't think this is a bug in GCC, rather the test is probably too strict and doesn't account for differences in the integration algorithm caused by rounding errors and optimisation. We should probably increase the test tolerance on this -- it would be interesting to know exactly where the difference is coming from first though, by comparing all the intermediate results at the two optimisation levels. This should be as simple as putting some breakpoints (or print statements) in qc25c for each computation of abserr. -- Brian Gough (GSL Maintainer) Support freedom by joining the FSF http://www.fsf.org/associate/support_freedom/join_fsf?referrer=37 _______________________________________________ Bug-gsl mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gsl __________________________________________________________________________________ Find local businesses and services in your area with Yahoo!7 Local. Get started: http://local.yahoo.com.au _______________________________________________ Bug-gsl mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gsl
