Re: [Bug-gsl] gsl-1.12 make check failure with gcc-4.4.1

[Gregery Barton]

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 <address@hidden>
To: Tasos Drosopoulos <address@hidden>
Cc: address@hidden
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
address@hidden
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