[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-gsl] gsl-1.12 make check failure with gcc-4.4.1
From: |
Gregery Barton |
Subject: |
Re: [Bug-gsl] gsl-1.12 make check failure with gcc-4.4.1 |
Date: |
Fri, 14 Aug 2009 13:36:44 -0700 (PDT) |
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