Does this is a loss of precision when using decimal floating types in GDB?
Junling Zheng
zhengjunling at huawei.com
Tue Apr 28 07:44:39 UTC 2015
Hi, all
When testing gdb in uClibc, a testcase(<gdb-7.6>/gdb/testsuite/gdb.base/dfp-exprs.exp) failed at:
166 gdb_test "p (_Decimal64) 3.1" " = 3.(0999.*|1000.*)"
And we got some unexpected results:
1) For most numbers, the trailing "0" will be left out:
(gdb) p (_Decimal64) 3.1
$1 = 3.1
(gdb) p (_Decimal64) 3.2
$2 = 3.2
(gdb) p (_Decimal64) 3.5
$3 = 3.5
(gdb) p (_Decimal64) 3.9
$4 = 3.9
(gdb) p (_Decimal64) 3.90001
$5 = 3.90001
2) However, for a little few numbers, the trailing "0" will NOT be left out:
(gdb) p (_Decimal64) 1.1
$6 = 1.100000000000000
(gdb) p (_Decimal64) 4.9
$7 = 4.900000000000000
And in glibc, the result is:
(gdb) p (_Decimal64) 3.1
$1 = 3.100000000000000
(gdb) p (_Decimal64) 3.2
$2 = 3.200000000000000
(gdb) p (_Decimal64) 3.5
$3 = 3.5 // followed IEEE Standard for Floating-Point Arithmetic (IEEE 754)
(gdb) p (_Decimal64) 3.9
$4 = 3.900000000000000
(gdb) p (_Decimal64) 3.90001
$5 = 3.900010000000000
(gdb) p (_Decimal64) 1.1
$6 = 1.100000000000000
(gdb) p (_Decimal64) 4.9
$7 = 4.899999999999999
According to the description in http://git.uclibc.org/uClibc/tree/docs/Glibc_vs_uClibc_Differences.txt:
...
stdio
-----
1) Conversion of large magnitude floating-point values by printf suffers a loss
of precision due to the algorithm used.
...
But I doubt that this is a loss of precision or a bug in uClibc or gdb?
Does anyone encounter this problem?
Cheers,
Junling
More information about the uClibc
mailing list