[armel] Function tgammal has precision issues in version 2.12.1-0ubuntu10.2 on ARM
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| Linaro Toolchain Miscellanies |
Fix Released
|
Undecided
|
Unassigned | |
| eglibc (Ubuntu) |
Undecided
|
Unassigned |
Bug Description
Consider the following test program :
#include <stdio.h>
#include <math.h>
int
main (int argc,
char* argv[])
{
long double x = 6.0;
printf("tgammal (%.20Lf)=%.20Lfn", x, tgammal(x));
return 0;
}
When run on 2.12.1-0ubuntu10.2, the result is :
tgammal (6.000000000000
while when run on 2.11.2-11 (glibc's unstable), the result is :
tgammal (6.000000000000
The second result is acceptable, while the second isn't. This makes sage (http://
Snark (julien-puydt) wrote : Re: Function tgammal has precision issues in version 2.12.1-0ubuntu10.2 on ARM | #1 |
summary: |
- Function tgammal has precision issues in this version + Function tgammal has precision issues in version 2.12.1-0ubuntu10.2 on + ARM |
summary: |
- Function tgammal has precision issues in version 2.12.1-0ubuntu10.2 on - ARM + [armel] Function tgammal has precision issues in version + 2.12.1-0ubuntu10.2 on ARM |
Dima Pasechnik (dimpase) wrote : | #2 |
The bug is in fact in lgammal, as tgammal(x) simply takes expl(lgammal(x));
namely, lgammal(6.0) produces 4.7874917427820
while it should be closer to 4.7874917427820
tags: | added: arm-porting-queue armel |
Launchpad Janitor (janitor) wrote : | #3 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in eglibc (Ubuntu): | |
status: | New → Confirmed |
Dima Pasechnik (dimpase) wrote : | #4 |
This boils down to eglibc working with 8-byte floats on ARM, even if it's declared long double.
To see this behaviour on x86, build and run the following:
#include <stdio.h>
#include <math.h>
int main ()
{
double x = 6.0;
printf(
printf("lgamma (%.20f)=%.20f\n", x, lgamma(x));
printf("tgamma (%.20f)=%.20f\n", x, tgamma(x));
printf(
return 0;
}
On eglibc you'll see:
sizof(double)=8
lgamma (6.000000000000
tgamma (6.000000000000
exp(lgamma) (6.000000000000
On a better libc (MacOSX 10.6 on x86_64):
sizof(double)=8
lgamma (6.000000000000
tgamma (6.000000000000
exp(lgamma) (6.000000000000
So eglibc does a bad job computing gamma() on double (i.e. on 8-byte floats) in this range of values (around 6.0).
Snark (julien-puydt) wrote : | #5 |
This is still a problem with 2.13-24ubuntu4.
Will Newton (will-newton) wrote : | #6 |
This seems to be fixed as far as I can tell building a static soft float binary with the Linaro toolchain (which incidentally no longer supports soft float from 4.9 onwards).
Changed in linaro-toolchain-misc: | |
status: | New → Fix Released |
Dima Pasechnik (dimpase) wrote : | #7 |
It would be great to know in more details how to get the fix mentioned on an armhfl Ubuntu 12.10 (no, we cannot upgrade the system, unfortunately).
I forgot to say that it was on an ARM (little-endian) box!